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:

1.  All Inkscape GSoC projects this year must be implemented as
   extensions, with no changes required to Inkscape's core

2.  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