Daniel Rall <dlr@collab.net> writes:
> 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."
I'm not sure this change is necessary; see below.
> 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.
I assume this is a reaction to Max's doing that option name thing late
in the recent release cycle...
This doesn't have to be about trust. Sure, probably Max knew that
some people would object to his quick change -- even though it had
technically met the standards for approval -- but his error was one of
tactics, not of attitude. It looks to me like he thought to himself:
"This change seems more than 50% likely to prevail in a post-facto
discussion, thus the best way to avoid delay in the release is to
get the change in, so that that discussion can take place *in
parallel* with the release rolling & testing. If the discussion
goes the other way, well, then we'll have to pull the change out,
but that doesn't result in much more delay than my insisting on
holding up the final release until the issue is settled anyway.
So the most efficient thing, in a perfectly rational universe, is
to put in the change as quickly as I can, according to the
technical rules of backport."
Note that this line of thinking does not, in the end, require the
issue to be settled in his favor. Does anyone here really think MaxB
would have filibustered the change, once the discussion had been had
in full? I don't believe it for a minute. So even if his proposed
change were eventually to be rejected, what he did could still have
been a rational way to proceed -- again according to some very
strictly rationalist thinking.
His mistake was not realizing the social consequences of the backport.
It would have been much, much better for him to not commit the
backport, and instead post saying:
"Go ahead with the current release candidate, but I'd like to start
a discussion now on this option name, and let's agree not to make
a final release until that discussion is settled."
That would have been the obvious thing to do; I think he overoptimized
for (perceived) efficiency at the expense of people's feelings. But
is this a trust issue? No. Max has been a valued developer for
years, I don't think he suddenly went off his rocker here, he just
made a innocent error.
[MaxB may wish to confirm or deny my attempts at telepathy above.]
One incident in one release cycle isn't enough to justify this edit to
hacking.html, IMHO. If similar things happen in the future, then we
should probably start talking about feature/bugfix cutoffs (as DannyB
just suggested in IRC). But if/when we do that, it would be nice to
do it with an understanding that growing pains are normal, and that
there may be multiple interpretations available for someone's
seemingly inexplicable behavior.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 5 23:47:18 2006