1. That page says 'obsolete' all over the top of it. 2. I can find you 27 email messages from board members and other crusty veterans to the contrary.
Quoting from the replacement page: -1 No. On issues where consensus is required, this vote counts as a veto. All vetos must include an explanation of why the veto is appropriate. A veto with no explanation is void. No veto can be overruled. If you disagree with the veto, you should lobby the person who cast the veto. Voters intending to veto an action item should make their opinions known to the group immediately, so that the problem can be remedied as early as possible. Now, the next question to ask is this: On what issues is a consensus _required_? That page lists a very narrow set of things. However, since that page is specific to the Apache HTTPD community, it's not binding on us, one way or another. However, it's always good for a community to make decisions by consensus in the general sense of the term. So, I ask my fellow -1 voters: who here thinks that by voting -1 they were irrevocably blocking consensus? I didn't. As a PMC member, I'm very much opposed to vetos on this sort of policy item; everyone should get a chance to express their views, and everyone should feel heard, and then a majority is good enough for me. On Sun, Jun 2, 2013 at 3:02 PM, Fred Cooke <[email protected]> wrote: > 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 <[email protected]>wrote: > >> On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <[email protected]> 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 <[email protected]> >> >> 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: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
