[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 31 Mar 2010 13:52:07 -0400

Greg Stein wrote:
> 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.

Good points, all. I retract the suggestion (and publicly admit my own
tendency to often wish to resolve questions before they are asked).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-03-31 19:52:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.