-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Jon Phillips Sent: maandag 25 februari 2008 1:50 To: Bryce Harrington Cc: inkscape-devel@lists.sourceforge.net; john cliff Subject: Re: [Inkscape-devel] Inkscape / GSoC '08 proposal
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...
To be honest, I find the 'extensions only' very limiting, so I like this compromise. Maybe incorrect, but I read the 'extensions only' as: python scripts only. I understand that new developers need time to get used to Inkscape's codebase, but devs like me can (and, personally, want to) go much much deeper.
Probably the time for gsoc's projects is really to short to do anything substantial and bugproof it aswell. Working in a separate branch is very nice, and I recommend it to all gsoccers. However, less people will use that branch to check for bugs and useability issues. For example, my LPE work was largely unnoted when it was a branch, except for a handful of people testing and commenting (thanks you guys!). But a lot of bugs were still unnoted and only became apparant a long time after gsoc had ended. In short: I am against keeping gsoc projects in branch until their end, they should be merged in and get some user attention before it.
What might be a good idea: have the first part of gsoc in branches. Then release 0.47, then merge gsoc into trunk for 0.48. This leaves very little time for 0.47 development though...
In any case, my GSoC'08 ideas for my own application could be: -1- LPE plugins (note the word LPE in front. I really first want plugins only for LPE, not tools, not other things, just LPE. It's because I have no experience with any plugin system coding, and I already have a good idea of what API must be available for LPE plugins. So, although it sounds exciting to have pluginable code, don't expect too much !) -2- Since refactoring was brought up: I'd be happy to work on 2geom integration. -3- Improved node editing: multiple paths, mask/clip on-canvas (already done ;), ... easiest
Sorry if this mail reads like a long rambling, Regards, Johan