Hi Wayne
Can we do this?
[3] I run committer elections for new developers who want to work in
GEF. The new committers complete the new commiter forms and for
foundation gets them processed. They are then "legal" to work on the
code in the exiting GEF project. There is no risk here since they are
working on a portion of their code in the GEF repository.
Is creating an incubator going to be faster than [3] ?
My only push back is that I would like to see new committers and their
GEF work being done on in GEF and not "somewhere else".
If we really feel a GEF incubator is the only way, then you have my
support.
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager
IBM Rational Software: Aurora / Modeling Tools
Phone: 613-270-4613
Inactive hide details for Wayne Beaton ---2010/02/08 10:52:21 PM---I
would like to better understand where the push back is comWayne Beaton
---2010/02/08 10:52:21 PM---I would like to better understand where
the push back is coming from. Anthony, are you concerned that this
means more work? Or
From:
Wayne Beaton <wayne@xxxxxxxxxxx>
To:
Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>
Date:
2010/02/08 10:52 PM
Subject:
Re: [tools-pmc] GEF Incubator Proposal
------------------------------------------------------------------------
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@gmail.com_ <mailto:cdtdoug@xxxxxxxxx>> wrote:
On Wed, Feb 3, 2010 at 10:23 AM, Wayne Beaton
<_wayne@eclipse.org_ <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@eclipsesource.com_
<mailto:irbull@xxxxxxxxxxxxxxxxx>
<mailto:_irbull@eclipsesource.com_
<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@gmail.com_
<mailto:cdtdoug@xxxxxxxxx>
<mailto:_cdtdoug@gmail.com_
<mailto:cdtdoug@xxxxxxxxx>>> wrote: > > I am
on the record a...
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>
<mailto:_tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>>
_
__https://dev.eclipse.org/mailman/listinfo/tools-pmc_
------------------------------------------------------------------------
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>_
__https://dev.eclipse.org/mailman/listinfo/tools-pmc_
--
Wayne Beaton, The Eclipse Foundation_
__http://www.eclipse.org_ <http://www.eclipse.org/>
I'm going to EclipseCon!_
__http://www.eclipsecon.org_
<http://www.eclipsecon.org/>
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_ <mailto:tools-pmc@xxxxxxxxxxx>_
__https://dev.eclipse.org/mailman/listinfo/tools-pmc_
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_ <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://eclipsesource.com/> |
_http://twitter.com/eclipsesource_
------------------------------------------------------------------------
_______________________________________________
tools-pmc mailing list
_tools-pmc@eclipse.org_ <mailto:tools-pmc@xxxxxxxxxxx>
_https://dev.eclipse.org/mailman/listinfo/tools-pmc_
--
Wayne Beaton, The Eclipse Foundation
_http://www.eclipse.org_ <http://www.eclipse.org/>
I'm going to EclipseCon!
_http://www.eclipsecon.org_ <http://www.eclipsecon.org/>
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
------------------------------------------------------------------------
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
