incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Approval for Lenya Release
Date Fri, 21 Nov 2003 15:52:04 GMT

Steven Noels wrote:
> The discussion on cocoon/incubator PMC lists was about whether the 
> Incubator PMC rather than the receiving PMC or mentors should vote for 
> an incubatee release. Nicola suggested that we should discuss this on 
> general@i.a.o. Pardon me for eventual context loss. Here it goes:
> ---------------------
> Nicola Ken Barozzi wrote:
>> The Incubator should try to minimize cross-votes, as they have shown
>> in practice to be very confusing and not productive.
>> I don't like this Mentor+Lenya+IncubatorPMC double vote either. The 
>> alternative is to have all Lenya committers on the Incubator PMC, but 
>> I don't think others are ready to accept it, nor if all the 
>> implications of it are clear.
> ... and I know for a fact that some, if not many Lenya peeps are *not*
> on any *@incubator.a.o list, perhaps hinting at a lack of interest in a
> one-for-all cross-project incubation mailing list,

Yes, I have noted that not all want to discuss about "general" 
incubation discussions, and I tend to think that this list is in fact be 
a place the incubator "developers" meet (mentors, incubator pmcers, 
incubator committers and others interested) and an entry point for new 

> or the centralization
> of 'power' in the Incubator PMC (that's my interpretation)

Centralization of power? Please explain.

> - I did hear
> some complaints about 'Incubator lists being noisy and not so helpful'
> during the Con.

Things are changing now, and I'm confident we won't hear that next year :-)

> You made a perfectly valid point about the license check around Xopus,
> but IMHO, we should require the Lenya peeps to do this themselves,


Never implied that we should do it for them. We must simply ensure that 
it gets done before a release.

> and
> try to preserve a sense of trust in the incubation process rather than
> having a strict command/control chain.

I don't get this.

> IMHO, 'any' PMC should be able to sign off a release, even of an
> incubatee, perhaps with a 72 hour ACK of the incubator PMC.

I disagree. PMCs have to endorse releases also for legal reasons, and it 
doesn't make sense that one PMC endorses the releases of a project under 
another PMC. Ever heard of Jakarta endorsing the Cocoon releases? ;-)

> Apart from
> the mentors who are on the Incubator PMC, the Incubator PMC is just not
> involved enough in the process leading to a release candidate in order
> to judge whether it can be released. 

 From a programming POV you are completely right. But that's not what 
the Incubator is here to check.

 > The receiving PMC might be neither
> (as my mishap clearly showed), so maybe just a sign-off by the mentors,
> possibly backed/vetoed by interested Incubator/receiving PMC peeps,
> should be enough as a 'formalization' of the process.

Well, that's basically the current process [1]: endorsement by the 
mentors and vote from the Incubabtor PMC.

What I specifically don't like is the need to get a vote from the 
Incubator PMC.

What about this (using a similar method used for adding members to a PMC):

1 - the project community + the mentors vote on a release
2 - if the vote is positive *and* mentors agree on the release, the
     mentors post the vote results to the incubator general list
3 - 72 hours after the post without problems been raised the release
     can be made

This ensures that

* the community learns to vote releases
* mentors can check the artifacts
* other pmc members can intervene but are not obliged to
* anyone can in fact intervene and check

Note that the 'project community' defined in point 1 is not necessarily 
the set of project committers, but can include also the sponsoring PMC.

For example in case of Lenya it can be decided that Cocoon wants to take 
part in the vote. It's not mandatory, but possible.



Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message