Daniel Berlin wrote:
>>
>> 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.
>
> I agree wholeheartedly with this.
I felt I was presenting logical reasons, and am a little miffed that you
characterize them so. Please at least explain *why* you find my
reasoning to be at fault.
> I introduced the flag with a name that made it clear what it did, with
> the expectation that the small number who needed it would figure out
> that they needed it when SVN reported an error message about the svndiff
> version being too new.
> To wit:
> "Oh, it says this repository has an unexpected svndiff version in it, I
> probably needed to create this repository with that crazy --no-svndiff1
> flag!"
OK, the name made more sense with that underlying assumption, but the
error message will be about a format mismatch, and does not mention
svndiff1. Also I think I remember Malcolm reporting that the error
message did not mention svndiff even before the format bump, instead
being something similar to "invalid insn, cannot decode diff stream".
> I honestly don't care what we name it (though i believe the new name is
> actually worse for users for much the same reasons as the other
> dissenters),
Could you explain your reasons, please?
The other dissenters are:
Branko:
to whom I responded explaining why I don't think the reasons
were valid.
Garrett:
who is neutral on the choice of name, and only finds the
timescale to be the problem.
Justin:
who had not posted objections to the name until after you wrote
the above.
> however, i am disappointed in the way this email discussion
> has gone.
>
> However, I honestly expected better than to see the typical (in bikeshed
> discussions) response that contained a list of:
>
> 1. "people i think agree with me"
> 2. "people whose emails i can kinda claim have no real opinion, but if
> you look close, really disagreed with me, even if for other reasons ",
> 3. "people who disagreed with me but who i think are wrong, and i've
> told them they are wrong, so that's that".
Since I was declining Garrett's request to revert, I felt I was obliged
to assess the spectrum of opinions presented so far in justification of
that, hence the list.
In point 2., you say that I have misstated the emails of others. I have
gone back and re-read all the emails sent before the one of mine to
which you refer, and I do not think I behaved as you say.
In point 3., "i've told them they are wrong, so that's that" is not
true. I provided reasons for my disagreement, and nowhere did I refuse
to listen to further comments.
> This is not the way to happiness.
>
> IMHO, A reasonable compromise position in this case would have been to
> just make the flag work with *both* names, and in the help text, note
> that one is just an alias for the other..
> It's not like we are running out of long option names for svnadmin create.
That would, I think, be the worst of both worlds, since most of my
objections are regarding 'no svndiff1' being an undesirable choice of
terminology itself, whilst also adding a new option would be more code
churn than a rename.
> In any case, this change isn't, and wasn't, important enough to hold up
> a release for.
I believe it has importance as it sets precedent for handling future
repository format bumps in the 1.x era.
> In the GCC world, at some point, the release branch
> becomes "regression fix only" (it eventually becomes bug-fix only again
> after release, for the next minor release). This means even *regular*
> bug fixes cannot be applied, only those that are regressions from
> previous versions[1].
We could potentially choose to adopt such a policy, but except for this
one present issue, informal decisions of whether a change is too big
have served us well.
> I also don't believe that we should care so much about compatability
> that if we wanted to rename a long option name for something pretty much
> unused, in svnadmin create, that this would be verbotten until 2.0.
In absence of actual documented rules, we've thus far assumed absolute
strictness except where unavoidable.
> [1] The first one to argue that a new option, "badly named", is a
> regression from a previous version is going to be publicly flogged.
*ahem* Actually, I think that logic has quite a bit of credibility :-)
Max.
Received on Thu Aug 24 17:40:42 2006