On Mar 14, 2006, at 5:48 AM, Rodent of Unusual Size wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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....
-dain
