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

Re: r21207 (Renaming --no-svndiff1 to --pre-1.4-compatible)

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-08-23 15:16:33 CEST

On 8/23/06, Max Bowsher <maxb1@ukf.net> wrote:
> Garrett Rooney wrote:
> > On 8/22/06, Max Bowsher <maxb1@ukf.net> wrote:
> >
> >> Once again, sorry for broaching such bikesheddy issue. I'm sorely
> >> concious that if I hadn't noticed that, we might have a RC5 within a few
> >> hours, but having noticed it, I could not in good conscience not take
> >> action to correct what I believe was a severe UI and API wart.
> >
> > Oh please, you're dramatically overstating the importance of this
> > change. The flag may be obscure, but its use case is also obscure,
> > there's no reason we should be wasting anyone's time on it when the
> > vast majority of users will never even need to know of its existence.
>
> It's a wart. Wart's aren't fatal, but they don't help anyone's
> impressions of Subversion. Since this is something that we are locked
> in to for 1.x once we release, I feel it had to be brought up, and it
> had to be brought up now.
>
> > This is 100% a bikeshed issue, and there is zero reason to bring it up
> > at this point in the release cycle. We have enough trouble fixing
> > actual problems, there's no reason to actively go looking for
> > pointless ones.
>
> That's the thing: *why* is it a bikeshed issue? It's a simple, dare I
> say trivial, renaming operation, for which I have explained the
> rationale. I hoped, and continue to do so, that people will recognize it
> as such: a trivial fix for some poorly-chosed terminology.

It's a bikeshed issue because it has to do with the UI and there are
at least two sets of opinions on the right way to do it. Additionally
it's about something incredibly trivial, which always helps to fan the
flames. You think it's a trivial fix because you happen to disagree
with the way it was done. Other people will think you're wrong. None
of it really matters because we're talking about a flag that almost
nobody will ever use.

> > For what it's worth, I would have +1ed it myself just to get the damn
> > thing off the radar except that I don't want to encourage people to
> > drop changes like this onto us at the last minute and then rush them
> > into a release so they can't be reverted, and I figured it was
> > incredibly likely that someone would object and require us to reroll
> > the RC anyway. And look, in response to one of the other emails about
> > this Brane already has objected. Please, just revert the change and
> > let us get on with this release.
>
> I see and recognize what you are saying about not encouraging
> late-breaking changes, but there is a different precedent that I am more
> concerned about not setting: I do not want it to be accepted that
> sometimes we sacrifice quality, even of things we are then obliged to
> keep for the entirety of 1.x, to get a release out sooner.

It's one thing to say "we shouldn't hold off a meaningful change
because we're about to do a release" and quite another to say "we
should stop a release any time anyone has a trivial problem they'd
like to address". I think we're firmly in category B here. It's like
calling "stop the presses" at a major newspaper because there's a typo
on page 6. Sure, you can fix the problem given the time, but
honestly, who cares. (Yes, I agree this doesn't have the same cost as
a "stop the presses" kind of thing, but there is still a cost in time
we all spend trying to get this release out the door.)

> The reactions of committers so far have been:
>
> You and Justin: Irked by the delay, but not commenting on the change itself.

I have commented on the change itself, I think it's 6 of 1/half dozen
of the other. The change doesn't matter. Virtually no user will ever
even use this option, so any time we spend arguing about it in EITHER
DIRECTION is wasted. We could call it --paint-it-pink and it would
only be marginally worse than it is now because despite the fact that
users would have zero way to tell what it does from the name it still
wouldn't matter because the vast majority of them still wouldn't ever
need to care about this functionality.

> David James: Expressed tentative positive reaction, on reading my email.
>
> Brane: Expressed misgivings, to which I responded with counter-arguments
> which, IMO, dispel them.
>
>
> That's not an adequate weight of opinion to recommend reverting as a
> course of action to me - not when the sole negative reaction against the
> change (rather than its timing) is one that I think I have suitably
> logically countered.

You've countered by saying "no, you're wrong, this is really better",
and since this is a UI thing with no clear answer Brane can just as
reasonably respond with "no, I disagree, you're wrong". There is no
way to win this argument in a reasonable amount of time.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 23 15:17:17 2006

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.