[proposal] Handling of contested changes near release finalization

[Daniel Rall <dl...@collab.net>]

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."


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.

Re: [proposal] Handling of contested changes near release finalization

[Karl Fogel <kf...@google.com>]

Daniel Rall <dl...@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

Re: [proposal] Handling of contested changes near release finalization

[Peter Samuelson <pe...@p12n.org>]

[Daniel Rall]
>   "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."

This leaves me wondering a couple of things.

1) _Why_ is a -1 not the correct way to contest a change late in the
release cycle?  What makes it necessary to allow other methods to do
the same thing?

2) Does this change the old policy, "if it didn't happen on the list,
it didn't happen"?  By saying "any forum" you seem to include IRC
channels and who knows what else.

Re: [proposal] Handling of contested changes near release finalization

[Daniel Rall <dl...@collab.net>]

On Tue, 05 Sep 2006, Karl Fogel wrote:

> Daniel Rall <dl...@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

Re: [proposal] Handling of contested changes near release finalization

[Karl Fogel <kf...@google.com>]

Daniel Rall <dl...@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.

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.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [proposal] Handling of contested changes near release finalization

[Daniel Rall <dl...@collab.net>]

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).

Re: [proposal] Handling of contested changes near release finalization

["C. Michael Pilato" <cm...@collab.net>]

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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand