corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Date Fri, 14 Aug 2015 17:23:13 GMT
On 14 August 2015 at 18:50, Dennis E. Hamilton <dennis.hamilton@acm.org>
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

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