Re: [Gnu-arch-users] "tla commit" generates a patch-set even if there are no changes

[James Blackwell]

(I replied to Bentley because I couldn't find the parent message)

Bentley makes some excellent points here. There is another point that
underscores his position.

The usage of arch has passed a milestone. Arch is not at the point where
the developers can only guess what parts of the tool are being
used and not being used. Once upon a time, say last year, everybody had
a very good idea of what everybody else was doing. This is no longer the
case.

As a case in point, recently I made a change to tla delta that cleaned
up the human side of the interface a bit, and made small modifications
that caused tla delta to act in a way that I thought 'most people' would
expect. Unbeknownst to me, Bentley was dependant upon some of the side
effects to the old delta. 

The "Bentley delta case" illustrates the point that I think the OP is
trying to make: That modifications to the existing interface is going to
step on somebody's toes. I believe this to be entirely true; as one of
the people that tends to work on the interface, many of my changes tend
to ruin *somebodys* day. 

So, what shall we do about this? Shall the interface be rendered in
concrete, as if it were a sidewalk, to provide users a safe passage? 

Before we do that, lets look at a large project that has done just this
thing; namely make. Make has a *HORRIBLE* interface. Tab here, space
there, if you switch the two up, things break. Know why make today is
the way it is? Back when make was an infant, they decided to cast the
interface in concrete because they had "dozens of users"! 

This is kind of where arch is today. Arch has a solid foundation. But
the interface isn't as consistant and intuitive as it could be. If we
were to cast our interface in concrete today, we would end up with all
sorts of problems with our 'interface sidewalk'. Our sidewalk wouldn't
be quite straight, would have cracks in it, and would be a trip hazard
where the sidewalk tiles had buckled and risen up.

Today, arch is still young. Yes, we have hundreds of users. But we don't
have either thousands of users (like subversion) or millions of users
(like cvs). 

As such, I really don't want to worry about today's users at the costs
of tomorrow's users. Sure, we may break the interface today and piss off
some of our users. Who knows. Maybe we'd even loose a few. More likely,
those with scripts will grumble and whine that the tool has changed, fix
their scripts. Two months later, they won't even remember that they had
to change the script.

What is the loss of a dozen users today, compared to the ease of use of 
millions of users a decade from now? 

Obviously, we should go through the pains of clearing up the interface
today. We should eliminate tripping hazards in today's interface by 
ensuring that all commands have a consistant interface (even if that
breaks the nine or ten scripts 'out there'). We should make sure that
our surface lines up as straight as possible today, so that when we do
cast our interface in concrete, we have a nice, straight path for users.

After all, once we set the interface in concrete, we're essentially
stuck with it for eternity.

Its *MUCH* too short-term-thinking to say 'Don't change the interface,
there are too many scripts dependant upon the way arch works today.'

I'm more than happy to make people change scripts today so that later
generations have an easier time of using our tool. L

Let me take the Steve Jobs approach. If we make a change today, that
change will cost humanity about 1 man hour(*1), but will save humanity
about 25 man years(*2) over the long run. For each three simplifications
we make to the interface today, we save a human life!

Those people that want the interface to be cast in concrete today, are
tantamount to murderers. You don't want to be a murderer, do you? :)


*1 If an interface change takes five minutes to fix, and there are
twelve scripts that are using that particular component of the
interface, then it will be 5 * 12 = 60 man minutes, or one man hour.

*2 If an interface change saves 4,000,000 users from having to do a 40
second help lookup 5 times (people are forgetful) then it will be
4,000,000 * 5 * 40 or 800,000,000 man seconds, or 222,222 man hours, or
25 man years.


Bentley wrote:
> Wazow wrote:
>> Aaron Bentley <address@hidden> writes:
>> 
>> 
>>>I said "the harm comes from changing the default behavior".  That's a
>>>script-unfriendly policy.
>>>
>>>
>>>>Your existing scripts would merely need to be changed to use the option.
>>>
>>>Yes.  In general, that's bad.
>> 
>> 
>> It has always been an advantage of free software projects that they are
>> legacy free (contrary to many commercial projects). Some free software
>> project took this compatibility breaking to the extreme (gcc and glibc
>> among the greatest).
>
> I don't see how that's true.  gcc and glibc are implementations of 
> established standards, as are the Linux kernel, Wine, Samba and Apache. 
>   Many gnu tools implement options as specified by POSIX, and they 
> recently changed the meaning of -H in ls for greater standards 
> compliance.  Can you imagine what would happen if gcc changed -Wall to 
> -Weverything?
>
>> It is nearly always the right thing to introduce
>> such a small inconsistency for the sake of better next release. 
>
> Yes, but what makes a "better next release" is up for debate.  I submit 
> that if you're going to break add-on tools, the value of the change must 
> justify it.
>
>> If
>> people really hate it then this could be made optional (whether --force
>> is default or not).
>
> It's already available as a non-default behavior.
>
>>>People should be able to update to the latest version of tla without
>>>breaking their existing tools.  I've found out just recently that I've
>>>been distributing an obsolete script, because tla shifted underneath
>>>me. I shouldn't have to test every script in my collection every time
>>>I do a tla update. 
>> 
>> 
>> You should.
>
> That's a tremendous, unjustified burden.  So long as tla commands do 
> what they've always done, my scripts won't break.  Should I also ensure 
> that ls -l still works every time I apt-get a new version?
>
>> In fact at least if you ship your scripts to the public you
>> should have a solid bunch of tests which you run before each release.
>
> I don't have releases.  Or did you mean tla releases?  Because I don't 
> have control over which version of tla people run, and gratuitous 
> changes just make it harder to stay compatible with all of 'em.  Any 
> test suite I did have would be considerably longer than the scripts 
> themselves.  One in particular just invokes tla changes --diff address@hidden
>
> Aaron
>
>
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>


-- 
James Blackwell          Please do not send me carbon copies of mailing
Smile more!              list posts. Such mail is unsolicited. Thank you!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400