This illustrates one of the problems of a <72 hour window. It is a social guideline that tries to ensure everyone has a chance to have their say.
That being said there are other ways of managing community interest. Since anyone (including a non-committer) can cut a release and call for a vote it is possible to say "we are going ahead with this release but feel free to cut a new release tomorrow with your fix in place". Since Cordova is tooling itself to provide rapid releases such an approach is more appropriate here than it is in other projects that do monolithic releases every few months. Ross Ross Gardler (@rgardler) Senior Technology Evangelist Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation On 19 February 2014 07:04, Ian Clelland <iclell...@chromium.org> wrote: > On Wed, Feb 19, 2014 at 8:30 AM, Mark Thomas <ma...@apache.org> wrote: > > > On 19/02/2014 12:31, Ian Clelland wrote: > > > On Wed, Feb 19, 2014 at 4:26 AM, Ross Gardler < > > rgard...@opendirective.com>wrote: > > > > > >> It's unfortunate that there are a couple of -1's on the current > release > > >> VOTE thread at a time where the Cordova project is being asked to > > improve > > >> their release processes. So as to avoid a potentially bad experience > > during > > >> this vote I want to ensure the community is aware of the voting > > guidelines > > >> for releases, > > >> > > >> Specifically I want to remind the project that a release is not > subject > > to > > >> a veto. > > > > > > > > > Thanks for trying to clarify here, Ross. > > > > > > Does this mean that the vote thread here is absolutely binding? That > is, > > if > > > there is no visible trail on the mailing list that anyone has changed > > their > > > minds, and after the allotted period, there are still more +1s than -1s > > > (from PMC members) that the release happens regardless? > > > > No. A release manager is free to cancel the release if they view that > > the issue that triggered the -1 vote(s) is serious enough to do that. > > They are also free to continue and do the release if they wish. > > > > Generally, when I have been the release manager for Tomcat and an RC > > gets a -1 vote I have cancelled the vote/release there and then as > > anything serious enough to trigger a -1 release vote is normally serious > > enough to cancel the release. > > > > I'm fairly sure (although I'd have to check the archives to be sure) > > that I have also proceeded to release anyway after someone votes -1 in > > at least one case. Usually the justification for carrying on is some > > combination of: > > - the issue is not a blocker (e.g. legal , license, etc) > > - the issue exists in the current stable release and no-one has > > complained about it > > - the release fixes an issue in the current stable release that folks > > have been complaining about > > - the issue is minor and can/should be treated like any other bug and > > fixed (probably in the next release) > > > > So the short version: the vote result provides the authority to release > > but does not mandate that the release happens. > > > > HTH, > > > > It definitely does, Mark -- thanks. > > I wanted to make sure, with a published 24 hour voting window, that we > didn't need to wake everybody who had already voted and convince them to > look at the -1s to prevent an automatic release. > > Glad to hear that there's some common sense in the loop :) > > > > Mark > > >
