subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: RFC: Release process amendment (was Re: Vetoing latest issue #3020 fix in 1.6.10)
Date Wed, 31 Mar 2010 17:37:29 GMT
On Wed, Mar 31, 2010 at 11:21, Mark Phippard <markphip@gmail.com> wrote:
> On Wed, Mar 31, 2010 at 11:10 AM, C. Michael Pilato <cmpilato@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

Mime
View raw message