Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tools-pmc] GEF Incubator Proposal

Excuse me if I'm over stepping my bounds (I'm not on the PMC, nor am I the GEF lead), but if you are committed to updating the EDP in the EclipseCon timeframe, does it make sense to use GEF (and a new GEF Incubator) as the guinea pig for this new process?

I would be happy with that.


On Tue, Feb 9, 2010 at 6:52 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
I apologise to Ian, Anthony, and all for commandeering this conversation...

This is one of those things that I'd like to chat about with you Doug.

I am committed to issuing a new update of the EDP in the EclipseCon timeframe. I am bothered that the committer community feels constrained by the letter of the process and the tools we have in place. From my point of view, there are several important principles that need to be upheld. The process is intended to facilitate those principles.

I think that all mature projects should probably have an incubator of some kind. Creating that incubator should be relatively easy. In fact, I'm pretty sure that we can tune the EDP to allow the creation of an incubator for a mature project in a very short period of time. 10 minutes might be aggressive, but I'm hopeful that maybe we can get it down to a day. It seems natural to me to allow/recommend the creation of an incubator with some subset of the existing committers during graduation.

I need to understand all the things that makes this hard/unpalatable so we can try and address 'em.


Doug Schaefer wrote:
It takes me 10 minutes to start a project on Google Code and do my first check in. How long does it take to set up an incubator?

On Tue, Feb 9, 2010 at 6:22 AM, Ed Merks <ed.merks@xxxxxxxxx <mailto:ed.merks@xxxxxxxxx>> wrote:


   In your most recent blog, you say:

       To me so much of the answer lies in ways to simplify the path
       for individual contributors to get code changes upstream into
       the Eclipse repositories.

   I'm not sure that suggesting folks host projects elsewhere is an
   effective way of doing that.  I like Wayne's ideas very much!


   Doug Schaefer wrote:
   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.


   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]



       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

       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

       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.


       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.

               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

                   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"

                       <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?


                       On Tue, Feb 2, 2010 at 10:20 PM, Doug
                       Schaefer <cdtdoug@xxxxxxxxx

                       <mailto:cdtdoug@xxxxxxxxx>>> wrote: > > I am
                       on the record a...

                       tools-pmc mailing list



                   tools-pmc mailing list
                   tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>

               --                Wayne Beaton, The Eclipse Foundation

               I'm going to EclipseCon!

               tools-pmc mailing list
               tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>

           tools-pmc mailing list
           tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>

       --        R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 |
       _______________________________________________ tools-pmc
       mailing list tools-pmc@xxxxxxxxxxx

       --        Wayne Beaton, The Eclipse Foundation

       I'm going to EclipseCon!

       tools-pmc mailing list
       tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>

   _______________________________________________ tools-pmc mailing
   list tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>

   tools-pmc mailing list
   tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx>


tools-pmc mailing list

Wayne Beaton, The Eclipse Foundation

I'm going to EclipseCon!

tools-pmc mailing list

R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 |

Back to the top