On Tue, 05 Sep 2006, Karl Fogel wrote:
> Daniel Rall <dlr@collab.net> writes:
> > 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?
>
> In general I agree. But it's a continuum: what if you'd talked to 50
> developers, and Mike was the only objector, and you knew you were
> unlikely to ever persuade him? Then you'd probably just commit the
> change.
For a development branch, I'd speak to Mike again, either before or
after making the commit. But for a release branch which is ready to
be finalized (especially after many months of work), I would not
commit a non-critical change. Under the circumstances, finalizing the
release would be a higher priority than making the release perfect.
After we came to a consensus (likely close to what I'd originally
proposed, if Mike is really the only one in dissent), the changes
would be introduced in a dot release, even if that meant carrying
around a little compat baggage.
> I'm not saying that's what happened here; I'm just saying this stuff
> is a lot harder to formalize than it looks. The mere presence of
> dissent becomes inevitable as the number of developers grows.
Indeed it does! While I agree that it's not easy to formalize, it's
for exactly the reason that dissent might become more common that I
think we should try to formalize a the decision making process for
this particular situation, or at least clear the air around it.
Judging from the conversations I've seen so far, takes on the anecdote
above vary widely.
Thanks, Dan
- application/pgp-signature attachment: stored
Received on Wed Sep 6 00:42:30 2006