That sounds like a reasonable compromise
On Sun, Feb 24, 2008 at 7:49 PM, Jon Phillips <jon@...235...> wrote:
On Sun, 2008-02-24 at 14:28 -0800, Bryce Harrington wrote:
On Sun, Feb 24, 2008 at 09:30:00AM -0500, john cliff wrote:
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?
It does impose some constraints, but I think it's a better option than sitting out SoC entirely this year. And constraints can sometimes have benefits - like doing B&W photography, it can eliminate a lot of complexity and let you focus on what really matters in your work.
We've certainly encouraged SoC'ers to use branches in the past. In this case it wouldn't help - it delays the added integration work, but
doesn't
let us avoid it. Indeed, given that our refactoring work is likely to move files around in the tree, eliminate some APIs and add others, the integration could become even more work than usual, and the more it's delayed the more work it becomes.
For similar reasons, while reducing the number of SoC projects may help, I think we maximize our benefit by having no inkscape-core SoC projects. A related idea would be to have the SoC projects be focused on the cleanup and refactoring work; I'm undecided on this - refactoring can require a depth of experience with the codebase that a fresh person may not have, but on the other hand if well directed a smart enthusiastic student could help steamroll through the work.
Half the idea is to get them working in a project environment too,
which
isolating them to extensions wont do either.
I agree that it's beneficial to give them a good project environment experience, but I don't think this will be isolating. Indeed, if all the projects are doing extension work, then they will be able to collaborate, share notes, code, and ideas and build up an inkscape extensions sub-community.
Obviously, it will be critical that we have good mentors who can help build this environment, and I'd consider this as a strong pre-requisite.
Bryce
How about this rule:
1.) Newbies to Inkscape must submit proposal with the infrastructure using the extension system
2.) Established developers who have either SVN commit access or 2 substantial patches can submit a proposal in any area.
The above approach takes into account the two possible types of submitter to GSoC, but also sets the bar high for deeper work...
Jon
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
-- Jon Phillips
San Francisco, CA CHINA PH +86 1-360-282-8624 jon@...235... http://www.rejon.org
MSN, AIM, Yahoo Chat, Skype: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897...
Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) Creative Commons (www.creativecommons.org) San Francisco Art Institute (www.sfai.edu)