Greg Stein wrote:
> 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.
Certainly it can be, but any bad form comes from the attititude expressed
along with the reversion, not the reversion itself.
> 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.
No, no it doesn't. It simply says "not having this commit is better than
having it, so let's make an incremental improvement by removing it.". I
explained what the problems were with the commit: One unequivocal real bug,
and one point where the design has been incompletely thought through.
> 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.
Exactly. This wasn't just an "I don't like this", it was a "look, there is a
real demonstrable and quite unpleasant bug". Thus, I took steps to get the
bug removed, so it wouldn't hinder the progression of 1.2, and suggested we
proceed with discussion to sort out how to do this properly. Granted, I
assumed that the fixed code would be placed in 1.3, not 1.2, but had no evil
motivation - I was just taking note that it was a new feature, and 1.2 is
branched, and we do not usually backport features.
> 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 clear problem, not merely a difference of opinions, I really
don't see why the above matters at all. The importance is all in the
justification of the action, not who takes it, for me.
> 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.
I basically said "This has problems {explanation} .... Let's discuss!"
I certainly do expect discussion!
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 7 02:20:52 2005