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? -- C. Michael Pilato <[email protected]> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
