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