GSoC
Project ideas for the Google Summer of Code 2010
Guidelines
Students
These ideas were contributed by developers and users of Kitware's open source projects, including CMake, CDash, VTK and ParaView. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply to. The mailing lists can be found on the project pages linked to in the preceding paragraph.
Adding Ideas
When adding a new idea to this page, please try to include the following information:
- A brief explanation of the idea.
- Expected results/feature additions.
- Any prerequisites for working on the project.
- Links to any further information, discussions, bug reports etc.
- Any special mailing lists if not the standard mailing list for the project.
- Your name and email address for contact (if willing to mentor, or nominated mentor).
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.
CMake
Project page, mailing lists, dashboard.
Project: CMake Project Generator
Brief explanation: The addition of a facility in CMake to automatically generate CMakeLists files based upon the source files present in a directory. So a developer can point CMake at a directory full of source files with a '--generate-project' argument for example, and automatically generate a project. This should detect if source files contain the QOBJECT macro, and need Qt's moc running on them, adding them to the appropriate CMake variable. This would be limited in scope to relatively simple projects wanting a single executable to be built from the source files, with some heuristics or switches to determine what toolkit etc it being used.
Expected results: A new facility added to the CMake suite of tools to generate simple CMakeLists files when supplied the path to a source directory. The user should reasonably expect to be able to run generate CMakeLists files, run CMake on these files and type make to build their project. Similar in functionality to the feature provided by qmake.
Prerequisites: Some familiarity with CMake, C++ and Qt.
Mentor: Marcus D. Hanwell (marcus.hanwell at kitware dot com).
CDash
Project page, mailing lists, dashboard.
Project: CDash Bug tracker integration
Brief explanation: A disconnect between CDash and bug trackers currently exists. Developers often want to link a current bug fix with a dashboard submission and, in order to achieve this feature, they currently enter the bug number in the commit log message. Moreover, new failures appearing on the dashboard should be ultimately entered and tracked in a bug tracker either manually or automatically. The goal of this project is to tie CDash and bug trackers to allow developers to link a current submission with a bug and track its evolution. Also, a continuous report should be generated to show the different builds leading to a bug fix (or bug report).
Expected results: Support for integration of bug trackers within CDash. Mantis (www.mantisbt.org) will be the primary bug tracker target but the framework should be flexible to support any other bug trackers (via Web API or other mechanism to be defined).
Prerequisites: Some familiarity with CDash. Familiar with PHP/MySQL/PgSQL.
Mentor: Julien Jomier.
VTK
Project page, mailing lists, dashboard.
