You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Steven Noels <st...@outerthought.org> on 2003/11/21 16:23:11 UTC
Re: Approval for Lenya Release
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, or the centralization
of 'power' in the Incubator PMC (that's my interpretation) - I did hear
some complaints about 'Incubator lists being noisy and not so helpful'
during the Con.
You made a perfectly valid point about the license check around Xopus,
but IMHO, we should require the Lenya peeps to do this themselves, and
try to preserve a sense of trust in the incubation process rather than
having a strict command/control chain.
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. 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. 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.
WDYT?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Approval for Lenya Release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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
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 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.
WDYT?
[1]http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Approval for Lenya Release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jeremy,
I agree entirely. Pretty much everything you just said is part of the
current discussion. Not sure why it is happening on the PMC mailing list,
other than that no one moved it, since there is really nothing sensitive
being discussed, just options for how to better structure oversight.
I'm curious to see how this will play out. I think that the approach would
be very good for the Incubator.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Approval for Lenya Release
Posted by Jeremy Boynes <je...@coredevelopers.net>.
Noel J. Bergman wrote:
> Steven Noels wrote:
>
>>Nicola Ken Barozzi wrote:
>
>
[ context not fully acquired ]
s/Lenya/Geronimo/
>
> As you know, we are discussing some options related to this topic. One
> would be that for a given subproject, we would have
> $subproject-pmc@incubator.apache.org, where the members of that list consist
> of the Incubator PMC, the subproject's committers, and (if there is one) the
> PMC for the destination TLP. So in the case of Lenya, that would mean the
> Incubator PMC, the Cocoon PMC and the lenya committers.
>
+1 for something where a subproject's committers can discuss things.
Events over the last week have shown a need for private discussion, but
by keeping this in the Incubator PMC you risk eliminating/alienating the
subproject's committers.
> That doesn't require all Lenya committers to be on the Incubator PMC, keeps
> the Cocoon PMC involved, and provides direct oversight from the Incubator
> PMC. The decisions are made in one place at one time, rather than spread
> out over time and project and people.
>
This also allows the committers of subproject without a destination TLP
to become intimately familiar with how a PMC operates, its duties and
responsibilities. Without this the community will struggle to acquire
the knowledge needed to stand alone.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Approval for Lenya Release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Steven Noels wrote:
> 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, or the centralization
> of 'power' in the Incubator PMC (that's my interpretation) - I did hear
> some complaints about 'Incubator lists being noisy and not so helpful'
> during the Con.
As you know, we are discussing some options related to this topic. One
would be that for a given subproject, we would have
$subproject-pmc@incubator.apache.org, where the members of that list consist
of the Incubator PMC, the subproject's committers, and (if there is one) the
PMC for the destination TLP. So in the case of Lenya, that would mean the
Incubator PMC, the Cocoon PMC and the lenya committers.
That doesn't require all Lenya committers to be on the Incubator PMC, keeps
the Cocoon PMC involved, and provides direct oversight from the Incubator
PMC. The decisions are made in one place at one time, rather than spread
out over time and project and people.
Thoughts?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org