On Tue, 05 Sep 2006, C. Michael Pilato wrote:
> 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?
Peter S. asked similar questions. I'll try to address both with the
following.
If Mike expresses dissent to me about a change I'd made in trunk while
we were walking towards Xebec (the bar near CollabNet), I'm not going
to port the change to another branch until we've reached some sort of
resolution, or at least continued discussion the following day (after
coffee clears the haze of the pints ;). I've always assumed this was
an unwritten understanding, but given the discussion on RC5 I've
returned to after vacation, perhaps it is time to write it down?
> 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.
More time might help things. However, if dissent with a change is
expressed, it's necessary to have a timeframe dictated by a resolution
being reached (or least a continuation of the discussion).
- application/pgp-signature attachment: stored
Received on Tue Sep 5 23:21:19 2006