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

On Mar 31, 2010, at 10:10 AM, C. Michael Pilato 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.

My statement was really meant to indicate that Paul and I were coordinating this effort, since today has been the planned day of a release for the last 2 weeks. It would be at least a little confusing if folks started yanking stuff from the branch on the day of a release *without* involving the RM.

But your point about folks choosing to -1 stuff after the fact is well taken. I don't see any circumstance in which the RM would intentionally stand in the way of somebody backing out a vetoed change.

> 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?

We actually have a bit of history in doing the opposite: a flurry of nominations, review, lobbying, voting, and merging just prior to the release. I'm a bit concerned that if we did implement a delay-release policy, it would degrade the quality of the release, or undesirably postpone releases.

The counter-argument, of course, is that we set the deadline not at the time of tag, but at the time of when the last merge can be performed. While possible, we may lack the discipline to *not* include a fix which receives its third vote shortly after this deadline, and for which there is significant community momentum. We could make exceptions, but once that happens, it's a slippery slope back to where we are today.

-Hyrum
Received on 2010-03-31 17:41:47 CEST