maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: [VOTE] Should we respin CANCELLED releases with the same version number?
Date Sun, 02 Jun 2013 19:41:42 GMT
I will point out that for this specific vote I listed three options and a
criteria. So this vote has no vetoes. Simple sum of all binding votes
defines the result. If the sum is < -3 then that says majority dont want to
burn version numbers. If the sum > +3 then that says the majority want to
keep release version number labels as immutable and therefore burn version
numbers with each cancelled vote.

After 72h the total, by my count was -3 and has only gone further in that
direction. I think the reuse of version numbers has one this vote. If Hervé
wants to call a second vote for burning qualified version labels, fine by
me but my view is do for all releases the same

On Sunday, 2 June 2013, Fred Cooke wrote:

> I apologise. I had three tabs open from Apache, and grabbed the wrong one.
>
> According to the correct, page, though:
>
> -0.9: 'I *really* don't like this, but *I'm not going to stand in the
> way*if everyone else wants to go ahead with it.'
>
> There's an *implication* there that an extra -0.1 might change that to I
> *am
> * going to stand in the way. There's also a disclaimer in the intro that
> says "might be interpreted" and a "TBS" (To Be Specified?) in the
> procedures section.
>
> I believe I've seen Mojo release votes (not code mod votes) vetoed, and
> they (we? ugh) claim to use the same rules. Correct me if I'm wrong
> (again).
>
> So, Apache elders, what IS the procedure voting ruleset, and who's going to
> update that page so that it's clear?
>
> Fred.
>
> On Sun, Jun 2, 2013 at 9:11 PM, Benson Margulies <bimargulies@gmail.com<javascript:;>
> >wrote:
>
> > Thanks, Baptiste, that's the reference I was looking for.
> >
> >
> > On Sun, Jun 2, 2013 at 3:08 PM, Baptiste MATHUS <bmathus@batmat.net>
> > wrote:
> > > That link is for HTTPd.
> > > For Apache general guidelines, read
> > > http://www.apache.org/foundation/voting.html
> > > -1 are only vetos for "code modification", not "procedural" issues .
> > >
> > > Cheers
> > >
> > >
> > > 2013/6/2 Fred Cooke <fred.cooke@gmail.com>
> > >
> > >> Benson, read the rules:
> > >>
> > >> http://httpd.apache.org/dev/voting.html
> > >>
> > >> "*-1 *No, I *veto* this action."
> > >>
> > >> +1 + -1 != 0
> > >>
> > >> On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies <
> bimargulies@gmail.com
> > >> >wrote:
> > >>
> > >> > On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fred.cooke@gmail.com>
> > wrote:
> > >> > >> from my experience, even if this question is not absolutely
> > >> > scm-specific,
> > >> > >> git
> > >> > >> brings us a new problem we didn't have with svn: once a tag
is
> set
> > on
> > >> > the
> > >> > >> canonical repo and replicated on developers' repos, it is
not
> > >> > automatically
> > >> > >> updated if updated in the canonical
> > >> > >>
> > >> > >
> > >> > > Git brings you no such "problem", it simply exposes your extremely
> > poor
> > >> > > practices... A tag should, and in any sane place is, permanent
and
> > >> > > irrevocable.
> > >> > >
> > >> > > On another note, the veto by -1 vote mechanism is a great idea
> for a
> > >> > > release, but a terrible idea for a principle like this. For a
> > release
> > >> it
> > >> > > requires a justification, for this it's just "my opinion"
> overriding
> > >> one
> > >> > of
> > >> > > Maven's core principals.
> > >> >
> > >> >
> > >> > Fred,
> > >> >
> > >> > Who says that anyone has a veto? As a principle of Apache, very few
> > >> > things are subject to veto, and I can't see how this would be one.
> If
> > >> > there's a clear majority of opinion in favor of burning versions,
> > >> > we'll start burning versions. I voted -1. I'll live with whatever
> > >> > outcome, but I'd live more happily with a more elaborated
> description
> > >> > of the resulting procedure. Like, where and how do we document these
> > >> > never-born releases, etc, etc.
> > >> >
> > >> > --benson
> > >> >
> > >> >
> > >> > >
> > >> > > Stagnation wins.
> > >> > >
> > >> > > Fred.
> > >> > >
> > >> > >
> > >> > >>
> > >> > >> but I may miss some git-fu once again...
> > >> > >>
> > >> > >> Regards,
> > >> > >>
> > >> > >> Hervé
> > >> > >>
> > >> > >> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> > >> > >> > >but as I see, there seems to be a consensus around
a 2-sided
> > rule:
> > >> > >> > >- don't reuse version number for pre-releases (RC,
etc)
> > >> > >> > >- reuse version number for actual releases
> > >> > >> >
> > >> > >> > Not sure how I feel about that.
> > >> > >> >
> > >> > >> > alpha/beta/RCx etc, they are all still valid version
nos, so I
> > think
> > >> > that
> > >> > >> > the no re-spin rule should still apply in the same manner.
> > >> > >> >
> > >



-- 
Sent from my phone

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