incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neha Narkhede <neha.narkh...@gmail.com>
Subject Re: concerns about high overhead in Apache incubator releases
Date Mon, 28 Nov 2011 19:00:52 GMT
>> That is because, every single time, the RM agreed that the release
was worth re-cutting.

We have been assuming that it is the rule of Apache to cut another RC even
if it gets a single -1 vote.

>> A majority of +1's over -1's is required, obviously :)

Although this seems reasonable, do people on this list believe this to be
true according to the Apache rulebook ?

In other words, can the podling RM and committers question and contest a -1
vote ? Is there any possibility of vetoing that ? If yes, who can do that
in what circumstances ?

Thanks,
Neha

On Mon, Nov 28, 2011 at 10:56 AM, William A. Rowe Jr.
<wrowe@rowe-clan.net>wrote:

> On 11/27/2011 3:34 PM, Benson Margulies wrote:
>
>> I think I've been leading a sheltered existence. In the TLPs of which
>> I play a part, over the 5 years or so that I've been around, I've
>> never seen a release proceed past a -1. Every single time, a -1 has
>> led to recutting the release.
>>
>
> That is because, every single time, the RM agreed that the release
> was worth re-cutting.  The vote hadn't (necessarily) failed... it was
> withdrawn for a better tag.
>
> When you get into complex alpha/beta releases, many projects will
> proceed, noting a -1 for some broken platform or broken feature,
> in order to get to the -next- alpha or beta release with that defect
> corrected, in addition to community feedback on the rest of the
> platforms and features.
>
> A majority of +1's over -1's is required, obviously :)
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<general-unsubscribe@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.**org<general-help@incubator.apache.org>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message