
I'd have thought that kills a lot of potential. How about we just make them use branches rather than head and are more selective about when it gets checked back into head? Its probably also a function of the number of them, maybe we should take less so that we dont tie up as many devs and cause as much churn? Half the idea is to get them working in a project environment too, which isolating them to extensions wont do either.
just my 2c
Sim
On Sun, Feb 24, 2008 at 2:18 AM, Bryce Harrington <bryce@...961...> wrote:
Hi all,
I'm hearing some rumblings that Google will be running their Summer of Code project again this year, and want to put out a proposal for discussion about how we should handle it this year.
SoC has been great for bringing new ideas to Inkscape from a number of sources, yet often the newly written code needs follow up work to sand rough corners or to make it fit more correctly within our architecture. However, between SoC mentoring during the summers, and release work at other parts of the year, core developers haven't really had a good solid amount of time to focus on this digestion. There is concern that another summer's worth of code would put us further behind in this regard.
Of course, given the major benefits that have accrued from our past involvement, it would be a shame to have to sit it out!
But I think there is a compromise which will solve this, if we set two criteria for this year's involvement:
All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
All mentoring be done by developers who will not be focusing on the 0.47 codebase refactoring efforts. (In particular, developers with good extension development experience.) We will limit the number of candidates we accept to the number of mentors available.
I think this approach will prove valuable in a few different ways. First, extension writing is likely going to be a much easier learning curve for students than learning to build and work within inkscape's codebase. Second, it keeps their code distinct and discrete from inkscape's codebase, avoiding any increase in 'entropy' in our core code. Third, it will help add value to our extension community, and give them resources to do achieve things that would have had trouble competing against core codebase feature priorities.
Please let me know what are your thoughts on this proposal? If you support it and have written extensions before, would you also be willing to be a mentor?
Bryce
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel