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 <bimargul...@gmail.com>wrote: > Thanks, Baptiste, that's the reference I was looking for. > > > On Sun, Jun 2, 2013 at 3:08 PM, Baptiste MATHUS <bmat...@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.co...@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 <bimargul...@gmail.com > >> >wrote: > >> > >> > On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fred.co...@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. > >> > >> > > >> > >> > -Chris > >> > >> > > >> > >> > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY < > >> herve.bout...@free.fr> > >> > >> wrote: > >> > >> > > yes, the vote for one unique rule is clearly "-1" > >> > >> > > > >> > >> > > 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 > >> > >> > > > >> > >> > > Regards, > >> > >> > > > >> > >> > > Hervé > >> > >> > > > >> > >> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit : > >> > >> > > > I will need to recheck the tally, but I think the result is > -3 > >> > >> > > > > >> > >> > > > So looks like we will be reusing version numbers on respins > >> > >> > > > > >> > >> > > > On Wednesday, 29 May 2013, Stephen Connolly wrote: > >> > >> > > > > We have been using a policy of only making releases without > >> > >> skipping > >> > >> > > > > version numbers, e.g. > >> > >> > > > > > >> > >> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc > >> > >> > > > > > >> > >> > > > > Whereby if there is something wrong with the artifacts > staged > >> > for > >> > >> > > > >> > >> > > release, > >> > >> > > > >> > >> > > > > we drop the staging repo, delete the tag, roll back the > >> version, > >> > >> and > >> > >> > > > >> > >> > > run > >> > >> > > > >> > >> > > > > again. > >> > >> > > > > > >> > >> > > > > This vote is to change the policy to: > >> > >> > > > > > >> > >> > > > > drop the staging repo, document the release as not > released, > >> and > >> > >> run > >> > >> > > > >> > >> > > with > >> > >> > > > >> > >> > > > > the next version. > >> > >> > > > > > >> > >> > > > > Under this new proposal, if the staged artifacts for 3.1.0 > >> fail > >> > to > >> > >> > > > > meet > >> > >> > > > > the release criteria, then the artifacts would be dropped > from > >> > the > >> > >> > > > >> > >> > > staging > >> > >> > > > >> > >> > > > > repository and never see the light of day. The tag would > >> remain > >> > in > >> > >> > > > > SCM, > >> > >> > > > > and > >> > >> > > > > we would document (somewhere) that the release was > cancelled. > >> > The > >> > >> > > > >> > >> > > "respin" > >> > >> > > > >> > >> > > > > would have version number 3.1.1 and there would never be a > >> > 3.1.0. > >> > >> > > > > > >> > >> > > > > This change could mean that the first actual release of > 3.1.x > >> > might > >> > >> > > > >> > >> > > end up > >> > >> > > > >> > >> > > > > being 3.1.67 (though I personally view that as unlikely, > and > >> in > >> > the > >> > >> > > > > context > >> > >> > > > > of 3.1.x I think we are very nearly there) > >> > >> > > > >> > >> > > > > Please Note: > >> > >> > > > >> > >> > >> > > >> > http://maven.apache.org/developers/release/maven-project-release-procedure > >> > >> > > > >> > >> > > > > .html#Check_the_vote_resultsdoes not actually specify what > it > >> > >> means by > >> > >> > > > > "the process will need to be restarted" so this vote will > >> > effect a > >> > >> > > > >> > >> > > change > >> > >> > > > >> > >> > > > > either outcome > >> > >> > > > > > >> > >> > > > > +1: Never respin with the same version number, always > >> increment > >> > the > >> > >> > > > > version for a respin > >> > >> > > > > 0: Don't care > >> > >> > > > > -1: Always respin with the same version number until that > >> > version > >> > >> > > > >> > >> > > number > >> > >> > > > >> > >> > > > > gets released > >> > >> > > > > > >> > >> > > > > This vote will be open for 72 hours. A Majority of PMC > votes > >> > >> greater > >> > >> > > > >> > >> > > that > >> > >> > > > >> > >> > > > > 3 will be deemed as decisive in either direction (i.e. if > the > >> > sum > >> > >> is < > >> > >> > > > >> > >> > > -3 > >> > >> > > > >> > >> > > > > or > +3 then there is a documented result) > >> > >> > > > > > >> > >> > > > > For any releases in progress at this point in time, it is > up > >> to > >> > the > >> > >> > > > > release manager to decide what to do if they need to do a > >> > respin. > >> > >> > > > > > >> > >> > > > > -Stephen > >> > >> > >> > >> > --------------------------------------------------------------------- > >> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > >> > >> > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > >> > > >> > > > > > > > > -- > > Baptiste <Batmat> MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
