RFC: Release process amendment (was Re: Vetoing latest issue #3020 fix in 1.6.10)

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