On 14 August 2015 at 20:25, Peter Kelly <[email protected]> wrote: > > On 15 Aug 2015, at 1:11 am, Dennis E. Hamilton <[email protected]> > wrote: > > > > With regard to what release votes are supposed to reflect, pre-voting > makes absolutely no sense to me. The ballots cast should follow a critical > review of the *specific* release candidate. > > > > I have said all I need to say about this. > > Maybe voting is not the best term to use for this period. The way I > understood it was a chance to hammer out last minute issues (like the line > ending problem I just mentioned) and once the all the issues I’ve found > have been sorted out, I give my +1. > > Keep in mind that release candidates differ slightly from other things we > normally vote on, because there’s sometimes obvious technical problems > (code not compiling, tests failing) that are not controversial, and are a > matter of fixing and issuing a new release candidate. > > If you have a suggestion for a less ambiguous term we could use so that > individuals can express the notion that all the problems they have > found/care about have now been fixed, I would be happy for us to change to > using that term instead. What is the typical practice on other ASF projects? > Most project I know of, actually call it [VOTE] and use the first part of the period to find and remove problems. But for obvious reasons, I saw a need to in our project to divide those 2 periods strongly, so nobody could be in doubt about what was going on.
We could e.g. easily start [VOTE] and decide the vote runs until 72hours after the last change, that way anybody who gave an early vote can change it. However this kind of voting assumes a rather big flexibility among the voters, but is in no way in conflict with the rules. I tried to do it so that nobody could be in doubt. And if Dennis do not understand what PRE-VOTE is, in comparison to [DISCUSS] and [VOTE] he should just read PRE-VOTE == DISCUSS. I did not use DISCUSS because we had that earlier when we decided what the content should be. Hope that clarifies matters. rgds jan i. rgds jan i. > > — > Dr Peter M. Kelly > [email protected] > > PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > >
