accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] Accumulo 1.8.0-rc1
Date Fri, 12 Aug 2016 19:40:34 GMT
On Fri, Aug 12, 2016 at 12:48 PM Josh Elser <josh.elser@gmail.com> wrote:

> IMO, you don't need to cancel this RC if there is agreement to extend
> the timeframe and there isn't anything found that needs to be fixed
> (avoiding referencing -1's because release votes are majority --
> Accumulo is different in that we often treat release votes as consensus).
>
> Making the vote longer is fine without re-casting it, making it shorter
> (but not shorter than 72hrs) would be bad thing to do.
>

Extending the vote duration during the vote is usually bad form, as it can
appear questionable, like you're only extending in order to achieve a
desired result.

In general, it would be better to explicitly cancel it, and issue a new one
with a new duration. Or, just let it play out, and issue a new one if it
fails (more -1s than +1s, or insufficient +1s).

Personally, I'm in favor of the latter... let it play out. If people get a
chance to test and vote, then great, there's nothing to worry about. If
people don't get a chance to test to their satisfaction, and not enough
people vote, then it won't pass. But others could test and +1 without them,
and it could still pass, and that's fine.

Since nobody has voted yet, you *could* extend it without the appearance of
impropriety, but personally I think it's better to just let it play out
rather than prematurely conclude not enough people will be able to test to
their satisfaction and vote.

As for the concern about making it standard for some releases being longer,
to account for more testing time.... I'm not a fan of that... it would be
better if folks got involved and did testing *prior* to voting. Extending
the voting period to account for last-minute testing from otherwise
inactive (or, at least, not-routinely-testing) developers does not seem to
me to be a good idea, because it seems to encourage an overall lack of
participation, except to weigh in and hold up things at the last minute.
I'm not implying that we have developers doing this... but I just wouldn't
want to encourage that sort of thing.

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