<mailto:
wayne@xxxxxxxxxxx>> wrote:
I would like to better understand where the push back is
coming from. Anthony, are you concerned that this means more
work? Or that the work will be split? Or that it will be
confusing for the community? Or confusing for somebody else?
I'm having trouble understanding the underlying problem. Sorry.
IMHO, Ian's item #2 is probably one of the best reasons to
create an incubator. Unfortunately, being a committer is a
binary state on a project: either you have access or you do
not. Earlier attempts at finer-grained access have resulted
in lots of misery for all involved.
Without the incubator, existing GEF committers will have to
work with contributors for any contribution. This takes time
away from other important GEF activities, like working on
in-plan items.
In the incubator, you can have a different set of committers
(which may intersect with the GEF committers) managing
off-plan contributions from the community while working on
new and innovative ideas. All this, under the supervision of
the "parent" GEF project. Some of these contributors can
become committers on the incubator and learn the social
conventions while they work on their cool new ideas; making
these people committers on the incubator will reduce the time
requirements from GEF committers (though somebody will have
to monitor these new committers to make sure that the
development process is followed). This pattern has been
followed by numerous mature projects.
I'm thinking of ways that we can make this better. Some thoughts:
1) Change the EDP so that mature projects can designate a
portion of their code repository as their "incubator" and
allow this portion to have its own set of committers, and
leverage parallel IP. This would require significant change
to the processes the Foundation has in place; as I go through
the mental exercise, it all feels just a little too cumbersome.
2) Relax some of the requirements on (some) projects. There
is some minimal project data at needs to be provided via the
portal (like description, source code URLs, that sort of
thing). Incubators, at least, shouldn't have to have
releases. Do they need to have plans? If we reduce the
requirements placed on an "incubator" project, does that make
creating one more palatable? I've been discussing this in my
blog [1] and in bug 300000 [2]
Wayne
[1]
http://dev.eclipse.org/blogs/wayne/2010/01/28/acknowledging-incubators/
[2]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=300000
Ian Bull wrote: