activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: ActiveMQ Graduation From Incubator
Date Tue, 14 Mar 2006 17:52:51 GMT
On Mar 14, 2006, at 5:48 AM, Rodent of Unusual Size wrote:

> Hash: SHA1
> Dain Sundstrom wrote:
>> When AMQ entered the incubator as a sponsored project from Geronimo,
>> the current understanding of incubator rules was that AMQ would
>> simply use the Geronimo pmc since the Geronimo pmc is expected to be
>> the home for the project.
> AFAIR, that was never *my* understanding.  AFAIK, that has
> *never* been the way the incubator has worked.  Every podling
> has supposed to have had a PPMC.  If I'm wrong, please correct
> me; where did you (and evidently others) read whatever it
> was that said a TLP PMC could serve for a podling?

If you remember back, Geronimo started in the incubator before there  
was the concept of a PPMC.  Geronimo was the first project to get a  
PPMC because geronimo was target to be a top level project.  All of  
the other projects in the incubator at that time were targeted to be  
subprojects to it made most since to get those sub projects working  
with their sponsoring pmc and the incubator was there to make sure we  
weren't ending up with umbrella subprojects, and instead projects  
that acted as a single whole.

>> If you ask me setting up a separate pmc for these projects is an
>> incrediably bad idea.  Our objective is to create a single community
>> between Geronimo, ActiveMQ, OpenEJB, ServiceMix and WADI.  Putting
>> these projects into separate boxes makes this very difficult.
> I believe there are two options:
> 1. Submit the code through the IP-vetting process.  The people
>    join the TLP dev mailing list and earn merit for commit over
>    time like anyone else.
> 2. Submit the code+people for processing through the incubator
>    as a podling.  The committers get commit access right away,
>    but now it's both the code and the community that's being
>    vetted.  And the eventual disposition of the podling is not
>    a foregone conclusion.
> There is no fast-track to commit access.

I don't want a fast-track to commit either (I have a long history of  
fighting that at Geronimo), but I believe we need a third option, in  
between the two you present.  Option 1 is clearly not appropriate for  
a project that has an existing community.  Option 2 is not  
appropriate for a project that is supposed merging communities with  
another.  Option 2 sets up a separate independent group, and once  
that is setup it will be hard to merge.  I think we need an  
incubation procedure that instead is designed to setup and assure  
that the new incubating group is merging the target communities and  
that incubation is only complete once continuous whole.  This is  
exactly what the Geronimo incubation were suppose to achieve.  In  
originally email I sent out on this and the conversations I had with  
a some of the board members before the email, I asked if we can  
"consolidate" our communities.  This is what everyone was excited  
about and thought was possible in the incubator and now I feel that  
the new incubation rules seem to be setup to prevent exactly this....


View raw message