Greg Stein wrote: > On Wed, Mar 31, 2010 at 11:21, Mark Phippard <markp...@gmail.com> wrote: >> On Wed, Mar 31, 2010 at 11:10 AM, C. Michael Pilato <cmpil...@collab.net> >> wrote: >>> Hyrum K. Wright wrote: >>>>> I'll work on a fix that can handle both use cases, but for now I am >>>>> changing my vote to -1 and reverting this backport. >>>>> >>>> And just so folks know, Paul's got the RM's blessing on this. >>> Great that he has your blessing, but I would suggest that he really doesn't >>> need it. We necessarily must allow for -1's to come late to the party in >>> the backport process, and for them to be binding-to-the-point-of-reversion, >>> even if they come -- heck, *especially* if they come -- from the person who >>> previously proposed or voted affirmatively for a backport. >>> >>> In fact, I would argue that we should never roll a release within so many >>> days of the most recent backport to the release branch, just to avoid any >>> threesome getting together to, intentionally or otherwise, railroad >>> last-minute changes into a release without time for other eyeballs. Why the >>> backport as the time-critical piece instead of the STATUS votes? Because >>> the backport generates a commit mail that folks are more likely to pay real >>> attention to than the STATUS churn. >>> >>> What do others think about this? Could we live with a policy change that >>> says that a release can only be cut 24 weekday hours after the most recent >>> non-trivial backport to its branch? >> I would be against this (-1) until such time that it manifested as a >> problem. The current system has been too valuable in resolving things >> like fixes to the bindings that no one had bothered to look at etc. >> Most importantly, the scenario you describe just has not been an >> actual problem we have faced so there is no need to develop a policy >> to block it. > > I'm with Mark on this one. > > The RM has a brain, and is given the "use your best judgement" baton. > We have ways to resolve RM problems.
Good points, all. I retract the suggestion (and publicly admit my own tendency to often wish to resolve questions before they are asked). -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
