On Wed, Mar 31, 2010 at 11:21, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Mar 31, 2010 at 11:10 AM, C. Michael Pilato <cmpilato_at_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.
Cheers,
-g
Received on 2010-03-31 19:37:58 CEST