Greg Stein <gstein@lyra.org> writes:
> 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.
I don't think that message is really inherent in a reversion (and
certainly Max didn't mean it that way), see below for why.
> 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.
(Are you sure you're not misapplying the RM role from other projects
onto Subversion? Our RM has never really been like that. For
example, any random developer will merge a change into the release
tree, once the change has enough votes. The RM's responsibilities are
mainly about making the release, not about exercising absolute control
over the release tree.)
I think this is just a situation where people may have different
expectations about "the norm". It's like tipping 10% in a country
where 15% is expected: it's not a matter of which number is right or
wrong, it's a question of what conventions are in effect. Along the
border region between two such countries, there might be a bit of
confusion sometimes.
Personally, I'd have no problem with Max reverting a change of mine if
he saw a big problem. Because it's all under version control, I
wouldn't feel that reversion makes the original change any less
accessible -- and therefore, the possibility of restoring it (with a
fix) is no more distant after the reversion than before.
IOW, reversion doesn't mean "I'm banishing this change forever". It
can just mean "This change has a huge problem, let's get it out of the
about-to-be-released tree while the problem is fixed." It's not like
the change has disappeared.
On the other hand, it's not hard to see the reasons behind Greg's and
Julian's position. It makes sense to do the original committer the
courtesy of letting them take responsibility for their own change.
I suggest that in the future, we try to either:
a) Point out the problem, and give the original committer a chance
to fix it (i.e., the Julian/Greg norm), or
b) Revert, but make it clear in the log message that the reversion
is simply because there's a need to get the bug out of the tree
quickly, for whatever reason (in this case, an impending release
candidate), and that the reversion is not intended to banish the
change forever (i.e., apparently the maxb/kfogel norm).
When there's no time pressure, I'd always go for (a) as well. I'm
just saying that when someone does (b), let's not read more into it
than the person intended.
If folks want to formalize a social convention for how
vetos/reversions should be done, go for it. I don't feel a strong
need, though, given that Julian was pretty easygoing about it even
though he was used to a different convention than Max.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 8 17:34:00 2005