On 14 August 2015 at 18:50, Dennis E. Hamilton <[email protected]> wrote:
> Jan, > > Help me understand this procedure a little bit better. > Sure, let me know, if you have open questions. > > I assume that if a new release candidate file is created, that rescinds > the previous votes, because they could not be about that version of the > file. (Maybe calling this a [PRE-VOTE] is not a good choice, but since > [VOTE]s are being collected, I am not certain what to call this procedure.) > > I also assume, were this a [VOTE] and the candidate changed, it would need > to be a new candidate (identified differently) and a new [VOTE] would have > to start? Presumably those who checked it before would double-check the > new RC and vote accordingly. > It would need to be a new candidate, but there are no naming requirements. And of course a new candidate means a new VOTE. You will see 2 ways of doing this: - Multiple votes and release candidates. Some projects and podlings start vote very early, and every time something is found a new candidate is made. - A single VOTE but a PRE-VOTE (I call it like that, because it is not a discussion, and not a VOTE) preceding. the PRE-VOTE stage, gives us all a change to check (eg. that the keys are correct) without having to restart the VOTE: When we start the VOTE it becomes a mere formality, because everything should have been cleared in the PRE-VOTE: We could name the release candidates .rcx some projects to do that. But I personally do not like that we vote about foo.r5.zip but upload foo.zip to the release server. I want to vote on the exact image that will be uploaded to dist. rgds jan i
