You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2015/08/14 18:50:05 UTC
[DISCUSS] [PRE-VOTE] Release candidate 0.1
Jan,
Help me understand this procedure a little bit better.
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.
Is that your understanding?
- Dennis
PS: Abstentions (0), like +1, require no explanation. An abstention is an abstention. I have nothing that I wish to say about the "=0".
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Friday, August 14, 2015 09:13
To: dev@corinthia.incubator.apache.org; Dennis Hamilton <de...@acm.org>
Subject: Re: [PRE-VOTE] Release candidate 0.1
On 14 August 2015 at 17:48, Dennis E. Hamilton <de...@acm.org>
wrote:
> =0 (binding)
>
> I do not give permission for this to be applied automatically to a genuine
> [VOTE].
>
there is no request for you to vote now, it is an option for those who want
to save mails, as I wrote, so no need
not to give perission.
It is much more interesting, if you found something wrong with the release
candidate, since you have a 0 and not a +1.
rgds
jan i.
[ ... ]
Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by jan i <ja...@apache.org>.
On 14 August 2015 at 21:04, Dennis E. Hamilton <de...@acm.org>
wrote:
> During many [VOTE]s, people often give a -1 (if thought critical) and
> state the conditions that will turn their vote into a +1. That is one way
> the situation that Peter raises can be handled.
>
> Note that while a -1 on a release [VOTE] is not a veto, the idea is that
> -1 votes are taken seriously and addressed if possible.
>
that is not the real problem. The problem is when the -1 leads to a new
release candidate then people who are very keen on rules, could say it
invalidates all previous +1 (since they votes on a different candidate).
rgds
jan i.
>
> - Dennis
>
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Friday, August 14, 2015 11:25
> To: dev@corinthia.incubator.apache.org
> Subject: Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
>
> > On 15 Aug 2015, at 1:11 am, Dennis E. Hamilton <de...@acm.org>
> 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?
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> 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)
>
>
>
RE: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
During many [VOTE]s, people often give a -1 (if thought critical) and state the conditions that will turn their vote into a +1. That is one way the situation that Peter raises can be handled.
Note that while a -1 on a release [VOTE] is not a veto, the idea is that -1 votes are taken seriously and addressed if possible.
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Friday, August 14, 2015 11:25
To: dev@corinthia.incubator.apache.org
Subject: Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
> On 15 Aug 2015, at 1:11 am, Dennis E. Hamilton <de...@acm.org> 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?
—
Dr Peter M. Kelly
pmkelly@apache.org
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)
Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by jan i <ja...@apache.org>.
On 14 August 2015 at 20:25, Peter Kelly <pm...@apache.org> wrote:
> > On 15 Aug 2015, at 1:11 am, Dennis E. Hamilton <de...@acm.org>
> 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
> pmkelly@apache.org
>
> 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)
>
>
Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by Gabriela Gibson <ga...@gmail.com>.
Not that it matters greatly, but maybe the term "Clearing" for this
preparatory process is a good fit.
G
On 14 Aug 2015 19:25, "Peter Kelly" <pm...@apache.org> wrote:
> > On 15 Aug 2015, at 1:11 am, Dennis E. Hamilton <de...@acm.org>
> 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?
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> 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)
>
>
Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by Peter Kelly <pm...@apache.org>.
> On 15 Aug 2015, at 1:11 am, Dennis E. Hamilton <de...@acm.org> 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?
—
Dr Peter M. Kelly
pmkelly@apache.org
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)
RE: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
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.
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Friday, August 14, 2015 10:33
To: dev@corinthia.incubator.apache.org
Subject: Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
[ ... ]
The offer for people to give their votes before the official [VOTE] period begins is an optional one, for the purposes of convenience. Anyone who wants to wait until the official [VOTE] starts before casting their vote is free to do so.
[ ... ]
Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by Peter Kelly <pm...@apache.org>.
> On 14 Aug 2015, at 11:50 pm, Dennis E. Hamilton <de...@acm.org> wrote:
>
> Jan,
>
> Help me understand this procedure a little bit better.
>
> 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.)
This period is for the purposes of letting people check to the file to see, e.g. if it compiles (the last release candidate didn’t for me). I expect there may be more release candidates if there are any more problems like that need to be fixed. Once the actual [VOTE] starts, that’s when the file must not be changed. The [PRE-VOTE] terminology Jan chose was to express the notion that it is *not* a [VOTE].
The offer for people to give their votes before the official [VOTE] period begins is an optional one, for the purposes of convenience. Anyone who wants to wait until the official [VOTE] starts before casting their vote is free to do so.
—
Dr Peter M. Kelly
pmkelly@apache.org
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)
Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by Peter Kelly <pm...@apache.org>.
> On 15 Aug 2015, at 12:45 am, jan i <ja...@apache.org> wrote:
>
> On 14 August 2015 at 19:35, Peter Kelly <pm...@apache.org> wrote:
>
>>> On 15 Aug 2015, at 12:23 am, jan i <ja...@apache.org> wrote:
>>>
>>> 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.
>>
>> Actually I think having .rcx would be good, because then we can easily
>> distinguish between the different versions, and when the official [VOTE]
>> begins it can be “Vote if you agree that foo-0.1.rc5.zip (with signature
>> 0xABCDEF) should become the official 0.1 release”. Then there’s no
>> ambiguity as to which actual file we’re voting on.
>>
> ?? there is not any doubt, the file we VOTE on (when that time comes) is
> the one uploaded to dist/dev/incubator... that file cannot change during a
> VOTE, if it does it is
> a new VOTE.
Ok that makes sense; as long as the file does not change after the VOTE has begun that’s fine. I think what confused me was that you talked about the file being uploaded to dist, when it’s already there.
—
Dr Peter M. Kelly
pmkelly@apache.org
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)
Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by jan i <ja...@apache.org>.
On 14 August 2015 at 19:35, Peter Kelly <pm...@apache.org> wrote:
> > On 15 Aug 2015, at 12:23 am, jan i <ja...@apache.org> wrote:
> >
> > 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.
>
> Actually I think having .rcx would be good, because then we can easily
> distinguish between the different versions, and when the official [VOTE]
> begins it can be “Vote if you agree that foo-0.1.rc5.zip (with signature
> 0xABCDEF) should become the official 0.1 release”. Then there’s no
> ambiguity as to which actual file we’re voting on.
>
?? there is not any doubt, the file we VOTE on (when that time comes) is
the one uploaded to dist/dev/incubator... that file cannot change during a
VOTE, if it does it is
a new VOTE.
Assume we vote on foo-0.1.rc5.zip (with signature 0xABCDEF), then I hope
someone secures that foo.0.1.zip is identical. We should also check that
the zip is the actual content of the release branch and I cannot see us
making foo.rcx branches.
rgds
jan i.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> 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)
>
>
Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by Peter Kelly <pm...@apache.org>.
> On 15 Aug 2015, at 12:23 am, jan i <ja...@apache.org> wrote:
>
> 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.
Actually I think having .rcx would be good, because then we can easily distinguish between the different versions, and when the official [VOTE] begins it can be “Vote if you agree that foo-0.1.rc5.zip (with signature 0xABCDEF) should become the official 0.1 release”. Then there’s no ambiguity as to which actual file we’re voting on.
—
Dr Peter M. Kelly
pmkelly@apache.org
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)
Re: [DISCUSS] [PRE-VOTE] Release candidate 0.1
Posted by jan i <ja...@apache.org>.
On 14 August 2015 at 18:50, Dennis E. Hamilton <de...@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