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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-03-31 17:11:03 CEST