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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 projects.
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,
+1
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 madeThis 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.
WDYT?
[1]http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
