I am a +1 now as well. @purplecabbage risingj.com
On Wed, Feb 19, 2014 at 5:15 PM, Andrew Grieve <agri...@chromium.org> wrote: > We've now worked through the issue I was worried about, and have determined > that the fix is in plugins only. So... > > +1 on this release! > > > On Wed, Feb 19, 2014 at 5:05 PM, Roy T. Fielding <field...@gbiv.com> > wrote: > > > On Feb 19, 2014, at 12:43 PM, Ross Gardler wrote: > > > > > A note on best practice. Prior to calling a release (i.e. when an RM is > > > stepping up to create a release) there should be a "[DISCUSS] release > > x.y.z" > > > > Some projects do that. Others use an issue tracker (like Jira or a > > simple STATUS file). It is also reasonable to schedule one regularly. > > Just understand that schedule != do. > > > > > This provides a place for people to air concerns without affecting the > > VOTE > > > thread. Ideally the VOTE thread is just a series of +1s and, in > > exceptional > > > circumstances, some -1's See my other thread for clarity on what -1's > > mean. > > > > Missed it, but I can explain. -1s are no more important than +1s. > > They express an opinion. Nothing more than that. > > > > > On 19 February 2014 10:37, Brian LeRoux <b...@brian.io> wrote: > > > > > >> This well illustrates my concern with tying a release to a vote > thread. > > >> There is always going to be a reason to -1, there will always be > > important > > >> fixes, and there's always going to be a delays. > > > > A -1 on a release is not a veto. It just means that person would prefer > > not to release this package. Why? They will probably explain, though > > it isn't necessary for them to do so (unlike a veto on a patch/commit). > > > > >> The security issues are definitely worthy of a patch release. I don't > > see > > >> these windows issues as blocker for this release. Indeed this release > > >> ideally happened a month ago. > > > > This is why release votes are a majority decision with minimum 3 +1s. > > Each person on the PMC has an independent right to make that call. > > Formal votes have a tendency to invite opinions that might otherwise be > > left unheard. > > > > My usual criteria starts with "is it better than the last release?" > > (note that there are a lot of things that could make it not better) > > and ends with "does an imperfect release now prevent shipping a better > > one next week?". There are no perfect releases. > > > > Nevertheless, this is a group decision in which each PMC member has an > > equal vote. Non-PMC member opinions are also important and might > > influence the RM or PMC. However, majority rules, and the release can > > go forward as soon as the PMC majority says it can. > > > > Earlier, Joe Bowser said: > > > > > This is only useful if your goal is to never release anything. > > > > Our goal is to be inclusive to community input on decision making. > > We respect the opinions of the community even when we disagree > > with them. Feel free to explain why your personal opinion differs. > > Do not dissuade others from expressing their own opinion. > > > > Do not assume that you speak for Apache Cordova. > > Only the result of voting speaks for the project as a whole. > > > > > > Cheers, > > > > Roy T. Fielding <http://roy.gbiv.com/> > > Senior Principal Scientist, Adobe <http://www.adobe.com/> > > > > >
