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

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 11:10:31 -0400

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

Received on 2010-03-31 17:11:03 CEST

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