With all the free open source hosting sites out there, if you
really wanted to do new work without the pain of the EDP you'd
host the new work there. Keep a good contributions log and bring
it into the Eclipse project with new committers in tow when it's
ready to "graduate".
BTW, I'm doing this with the Objective-C support for CDT, which
is currently hosted at Google Code. When we get to a point where
I can have a committer to take care of it, I'll bring it home.
Doug.
On Mon, Feb 8, 2010 at 10:51 PM, Wayne Beaton <wayne@xxxxxxxxxxx
<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:
Actually, while I think making this part of GEF proper could
work, the more I think about it the more an incubator makes
sense.
1. GEF is clearly a mature project in maintenance mode.
Many of the ideas being presented in this proposal stray
well off the beaten path. An incubator will help ensure
that GEF maintains it's current direction in the short term,
with the possibilty of new ideas flowing in down the road.
2. The people doing the work are (for the most part) not
active committers on other projects. An incubator will give
us a chance to help mentor them.
3. The GEF project, follows a similar plan as the platform
(with respect to schedules, etc...). Forcing new ideas to
follow API freeze rules (for example) will only stiffle
innovation.
We could, if it makes more sense, propose this project under
"Technology". But since this is tied closely to GEF, a
tools project (IMHO) seems appropriate.
cheers,
ian
On Wed, Feb 3, 2010 at 9:02 AM, Doug Schaefer
<cdtdoug@xxxxxxxxx <mailto:cdtdoug@xxxxxxxxx>> wrote:
On Wed, Feb 3, 2010 at 10:23 AM, Wayne Beaton
<wayne@xxxxxxxxxxx <mailto:wayne@xxxxxxxxxxx>> wrote:
Another benefit is that you can have a lower bar for
committers on the incubator. You can use the
incubator to grow folks into committer-worthy
status. Just a thought
The bar is as high as the existing committers set it.
;). I'm still hoping for the "Eclipse Labs" concept to
develop so we can create such sandboxes there.
Wayne
Doug Schaefer wrote:
BTW, the only benefit would be parallel IP. You
can do those other things without the hassle of
creating and managing a second project. And even
parallel IP could be handled by storing the
initial code off site. Until it's ready for the
review.
Of course, if you want to do it, I'm fine with
that. It just a pet peave of mine.
On Feb 3, 2010 8:56 AM, "Ian Bull"
<irbull@xxxxxxxxxxxxxxxxx
<mailto:irbull@xxxxxxxxxxxxxxxxx>
<mailto:irbull@xxxxxxxxxxxxxxxxx
<mailto:irbull@xxxxxxxxxxxxxxxxx>>> wrote:
I don't know, that's a good question. I
thought that incubators provided a number of
advantages for new projects and new ideas,
such as:
* Parallel IP
* Pre 1.0 (wrt to API)
* A clear indication to early adopters of
what to expect
I don't have a problem with creating this
work as a sub component of GEF, although
some of this work is clearly "incubation"
style work (new ideas with undefined API
that will hopefully graduate -- but that
will depend on the quality and demand of the
work being done).
Anthony, as the GEF lead, what do you tihnk?
cheers,
ian
On Tue, Feb 2, 2010 at 10:20 PM, Doug
Schaefer <cdtdoug@xxxxxxxxx
<mailto:cdtdoug@xxxxxxxxx>
<mailto:cdtdoug@xxxxxxxxx
<mailto:cdtdoug@xxxxxxxxx>>> wrote: > > I am
on the record a...
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
<mailto:tools-pmc@xxxxxxxxxxx>
<mailto:tools-pmc@xxxxxxxxxxx
<mailto:tools-pmc@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/tools-pmc
------------------------------------------------------------------------
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/tools-pmc
--
Wayne Beaton, The Eclipse Foundation
http://www.eclipse.org
I'm going to EclipseCon!
http://www.eclipsecon.org
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/tools-pmc
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/tools-pmc
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
------------------------------------------------------------------------
_______________________________________________ tools-pmc
mailing list tools-pmc@xxxxxxxxxxx
<mailto:tools-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/tools-pmc
--
Wayne Beaton, The Eclipse Foundation
http://www.eclipse.org
I'm going to EclipseCon!
http://www.eclipsecon.org
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/tools-pmc
------------------------------------------------------------------------
_______________________________________________ tools-pmc mailing
list tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/tools-pmc
