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
