[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Very emphatic -1 for r13369 (svn:keywords canonicalization)

From: Greg Stein <gstein_at_lyra.org>
Date: 2005-04-06 23:42:10 CEST

On Wed, Apr 06, 2005 at 02:07:43PM -0500, kfogel@collab.net wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
> > Max Bowsher wrote:
> > > On this basis, I am about to revert the revision in question, and
> > > call a vote in the 1.2.x STATUS file for reverting it there too.
> >
> > By the way, it was me that committed that patch on behalf of another
> > contributor, and I would have been happy to revert it myself if you
> > had just pointed out this problem and suggested reverting it. It is
> > usually considered rude to revert someone else's work without first
> > giving them the chance to fix it. Don't worry about it this time,
> > though - I'm cool :-)
>
> Just FYI, I've never felt that way, since it's as easy to unrevert+fix
> the reversion that someone else did. It's all under version control,
> therefore it's all easy :-).
>
> I think Max just wanted to act quickly due to 1.2 scheduling.

I concur with Julian. Reverting somebody else's work is (IMO) bad form.

Recognize that a very likely outcome would be to fix the change rather
than to back it out. By stepping in and reverting the change you are
essentially saying, "I'm vetoing this and there is nothing you can do
about it. There is no other resolution we can come to. Don't even
bother to ask." It completely shuts down any discussion about the
change.

A veto is supposed to mean, "I disagree with this change. Let's talk
about it." Stuff is not allowed to ship with vetoed code in it, sure,
but there should be an assumption of *discussion* rather than
unilateral action.

I'm not sure how to stress this any more. Let the original committer
revert the change, or fix it. A vetoer should never do that.

If there is a time pressure due to a release, then the *RM* can
certainly revert the thing in the release branch (or possibly on trunk
if that's where the release is coming from; tho I'd recommend a
branch, a reversion, and then release). The RM is free to take this
kind of action. Developers should not; this isn't about "easy" or
"hard" but about social dynamics and the expectation of discussion.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 7 00:48:01 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.