I have registered the GIMP as a mentoring organisation for the Summer of
Code (I had been in contact with Google before the announcement), we
should be up on the page over the next couple of days.
Our next requirement is a list of project ideas for people to take on -
these should be:
- Suitable for an advanced student, for 10 weeks work (1/2 weeks
planning, 4 weeks coding, 2/4 weeks refining, 1/2 weeks for report)
- Have a mentor associated
- Be on a publicly accessible web-page (the wiki will do)
- Be interesting and useful (perhaps it goes without saying, but
"document the API of library X" would not qualify)
I had some ideas:
- Scripting languages and the GIMP - work on ruby or python bindings
- Plug-ins: Save for web for example (too small to be a project, but
could be part of one)
- Effect layers - I think this is fairly straightforward with the GIMP
as it is, it's a nice chunk of a project, and would be a nice feature
- Vector layers (or replace GFig plug-in by Inkscape plug-in?)
- Tools - shapes, intelligent eraser?
There are lots more, but you get the idea.
The way I see these projects being integrated into CVS is:
1. Feature freeze 2.4 soon (before the end of May), for release during
2. Create SoC branches for integration of the SoC projects
3. After release of 2.4, merge successful projects to HEAD, and release
2.5.0 (GIMP-SoC) in September. Let the branch harden for a month or so,
and release 2.6.0 off that.
4. Start gegl integration on a branch, if needs be, and integrate that
work into HEAD straight after the release of 2.6.0.
Of course, I could be on crack. But it seems like it's important (if you
look at other projects) for SoC code to be integrated into a stable
release as soon as possible if you want to keep the contributor.
Gimp-developer mailing list