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

[proposal] Handling of contested changes near release finalization

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-09-05 22:41:19 CEST

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

The stipulation of not porting non-critical changes is a best-practice
typically used by successful development projects.

The trust that committers extend to each other to freely make changes
to development branches should be reciprocated when there are
reservations about porting changes to a release branch. This is
especially imperative near the end of a release cycle.

  • application/pgp-signature attachment: stored
Received on Tue Sep 5 22:40:25 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.