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

Re: [proposal] Handling of contested changes near release finalization

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-09-05 22:59:30 CEST

Daniel Rall wrote:
> Given the consensus-based nature of our development process, I propose
> that something along the lines of the following be incorporated into
> HACKING to streamline the decision making process near the end of a
> release cycle (hopefully speeding up future release timelines):
> "Contested changes of non-critical functional severity should not be
> backported during a release candidate cycle which is likely to
> result in a final release. A change is "contested" not only by a -1
> veto in STATUS, but by negative feedback from a committer in any
> forum."

We have a mechanism for indicating dissent. Why do we need to expand
that mechanism to include off-hand remarks between committers walking
down the sidewalk toward the local pub?

Instead, I think what is needed here is Time -- ample time between the
introduction of a matter proposed for backport and its closure. For
example, a rule that said that no change proposed for backport could be
approved and merged without having lived as a proposal for, say, 48 hours.

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Tue Sep 5 23:01:07 2006

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.