On Wed, Feb 15, 2017 at 8:17 PM, Julian Hyde <jhyde.apa...@gmail.com> wrote: > While I agree with what both John and Marvin are saying, the key word here > is “discretion”.
+1 for IPMC members applying discretion. I've submitted some suggestions which I hope other IPMC members will consider, and I've tried to think them though carefully, but situations will inevitably arise where the suggested workflow is an awkward fit. For instance, a judgment call is required when there's a dispute as to whether an issue was fixed, as John discusses elsethread. > Obviously the IPMC shouldn’t give podlings too hard a time > (we all know how difficult and time consuming it is to go through a cycle > consisting of a release candidate and TWO votes, and the mechanics of the > release process are intimidating to the uninitiated). But also IPMC members > are at liberty to say “I don’t like the look of that, I’m voting -1”. A -1 > doesn’t veto a release (we just need 3 more +1s than -1s), and IPMC members > can always change their vote after a discussion. It seems we're basically on the same page. However, there have been multiple instances going back a ways where the IPMC had the option to let through a flawed but legal RC, yet the podling was asked to respin. This thread isn't just in response to the recent Traffic Control vote. I'm not sure it's been clear to all our IPMC members when the option to approve a release with policy flaws is available, so I thought it was worthwhile to review the rationale and to analyze some of the most common cases. Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
