[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"cvs [commit aborted]: cannot commit files as 'root'"

From: Lenny Foner
Subject: "cvs [commit aborted]: cannot commit files as 'root'"
Date: Mon, 9 Jul 2001 01:03:36 -0400 (EDT)

Greg.  Greg, Greg, Greg.

I've been watching your traffic on info-cvs since about August 1996.
That's over 100 meg of traffic.  Of course, not all of it is yours.

In that time, you've come across as basically a reactionary force,
in the original meaning of that term---in other words, just about any
change to CVS has launched you on a crusade to preserve the One True
Original Implementation, even in the face of lots of people who might
rather it behaved otherwise.

You've generally shouted down many attempts to change CVS via bluster,
zillions of increasingly-inflammatory messages (in which the count of
exclamation marks increases exponentially over time), and apparently
having more time than anyone else who cares to shout ever more loudly
about what -you- want CVS to be.

People who don't have time to spend arguing with you simply leave.

This is a common occurrence in all sorta of fora.  Various experiments
in self-governance in MUDs, for example, have failed by being taken
over by people who have no lives.  Such people spend more time
shouting than people with better things to do, and win by driving
everyone reasonable away.  This effect has been documented by numerous
academic papers which look at the sociology and anthropology of online

On this list, -you- seem to have that role.

I'm going to respond -just once- to your latest scream, and then I'm
going to abandon this thread no matter what you say.  I don't have the
time.  If someone informs me that patches to make CVS easier to use
would be accepted, I may well write some.  Other people might, too.
(Obviously, I'd be more than happy to participate in a discussion of
how such a patch should be designed.)  Of course, the more likely
outcome is that any patches intended to make life easier for the
users, no matter how rational, will simply be shouted down by you.
Thus, there -aren't- any such patches, because nobody wants to waste
their time writing them when you'll try to shout them off the stage.

This is the sort of behavior that leads to forking the code in order
to make progress.  Perhaps this should have happened years ago.  Of
course, maybe the most productive approach would be to create the Greg
fork, and the fork everyone else uses; that avoids having two large
but splintered groups of users, as seems to have happened with the
*BSD forks of various things already.  I should note that I am -not-
the first to suggest a Greg fork; this alone might give one pause.

Given your repeated screams of "RTFM!", I must conclude that you hate
CVS' users and wish to punish them.  (It's especially ironic in this
case, since you've said yourself that this particular error message
never got documented in the M to begin with.)  I don't share that
viewpoint.  And, given the message traffic on this list, I'm willing
to believe that the people who write here asking questions don't share
that viewpoint, either.  And I'll bet that those few selfless
individuals who seem to spend a great deal of time answering their
questions don't share that viewpoint, either, and would rather that
users could be made more independent.  What's wrong with empowering
the users?

Now, let me address your particular points.  As I see it, they are all
strawmen, but you need to have them in order to bluster more effectively:

o  You've said quite clearly that making things easier for users is
inherently bad, e.g., that they must not be enlightened through the
actual error messages, but merely given -just- enough information to
be able to find out something about the error in the manual.  This
seems an extremely curious attitude; I wonder if it is widely shared.

o  You've spent lots of bluster talking about time and resources, but
have failed to actually mention what resources those are.  I contend
that those resources break down into an insignificant amount of memory
and load-time (and you did not refute those), some amount of CVS
developer time, and some amount of time to make sure that front-ends
can parse the results.  It is my contention that the developer-time
required to dramatically improve the situation (see below) is
insignificant when compared to the users' time, and the time of
those who read this list, that is wasted by not doing so.

o  You claim that front-ends cannot handle more-useful documentation,
but that's clearly a strawman argument.  As I demonstrated, it
wouldn't be hard to embed some unique identifier into -every-
message that CVS emits, and front ends can trivially look for it.

o  You claim that I must clearly be inexperienced, both as a programmer
and in CVS internals, to have made the assertions I did.  Having been
a programmer since 1973 and the days of the PDP-8, I can assure you
that I'm not.  I've done work in speech recognition.  I've helped
build Ada compilers.  I was a systems programmer for many years on
Lisp Machines.  I've done more communications-related programming than
I can remember.  I've built commercial expert systems in a variety of
languages, and indeed my undergraduate thesis was in AI.  My doctoral
work at the MIT Media Lab involved distributed cryptographic systems.
And I've read the majority of CVS' code as well.  So I think we can
demolish the "you don't know what you're talking about and you don't
know the program" strawman blusters, too.  Just because I've kept very
quiet on the list all these years doesn't mean that I haven't been

o  You claim that making error messages more understandable must be
turning CVS into some "fancy GUI-driven DWIM application".  Surely you
must realize that this is not the case.  Adding a couple sentences of
explanation for an error message that has been confusing users for
-years- is not the same as adding a GUI---and GUIs with terse,
confusing error messages are -just- as frustrating to their users
as are command-line tools with terse, confusing error messages.

o  You spend quite a bit of both messages loudly proclaiming that
-your- tastes must necessarily be shared by all, or at least a
majority, of other users.  I don't see that we have the data to
support that.  Do you?  Tell me, what release of CVS are you running
right this second, anyway?  Would such changes impact you?  I seem to
recall traffic from you saying that you were running old releases
anyway; why would you care?

o  One trivial way to let you have your cake, yet improve CVS, -and-
not fork the code, would be a compile-time switch that says, "Keep all
CVS messages the way they were in Ye Olden Dayes."  If, for example,
all the additional explanatory bits of the new, improved error
messages came after some separator character (or merely after the first
line), then one could make all error message emissions go through some
single function that simply omitted anything after that point, if the
switch was thrown.  I don't recommend this, and think that it's not a
great idea, but you must admit that it would be very simple to do.

o  You spend two messages screaming, in an increasingly frenzied
fashion, that this is -must not- be done---but then you turn around
and ask, "So? Where are the patches?"  If you think it shouldn't be
done, -and- if people with control of the release branch care what you
think, then it would be a waste of anyone's time to write such
patches.  If that's not the case, then rational discussion about what
form they should take should -clearly- precede their implementation.
You know---design first, implement second.  There are a number of
design questions that should be answered first, such as "How hard
would it be to change error messages? Do any clients break? What takes
more than five minutes to fix? How can we test it? How can we improve
interoperability and compatibility in both directions?"  All of these
questions are reasonable to ask, and many may have very simple
solutions.  But there's little point trying to discuss the issue if
it will be continually side-tracked by you screaming that it's a
fundamentally evil idea to make CVS easier to learn and use.

o  There are counterexamples, in other systems, to your assertions
that long error messages are inherently problematic.  For example,
let's take the Lisp Machine NFS client and server implementations,
originally written by Chris Lindblad.  Those implementations were known
to spit out 3- and 4- paragraph errors when a configuration error was
detected.  Why?  Because configuring NFS, especially when you have to
make things work right between Unix boxes and Lisp Machines (which
have radically different ideas of what a file is, much less whether
authentication matters or not), is a difficult and error-prone
process.  Chris clearly decided to reduce the cognitive load on the
poor sysadmin who was trying to configure the system, by having the
machine explain what -it- thought was going on, what the most likely
couple of reasons were that things weren't working, and exactly where
in the documentation set a more-detailed discussion could be found;
this latter was available in a single mouse-click, because Lispms had
a hypertext documentation system years before the web existed.  Yet
rather than complain to us that the error messages were too long, we
got rave reviews from our users, who told us that often such messages
made it instantly obvious what they had done wrong.  This had a direct
effect on our bottom line, because such users spent much less time on
the phone with our support personnel trying to get NFS working.  Yet
if it took Chris even one entire afternoon of extra effort to make
those error messages so verbose, I'd be very surprised.  After all,
-he- knew exactly why the error was being emitted, and so he typed in
the reason to the error message itself.  That's just a few minutes per
message.  (And I should point out, by the way, that Lispm users were
typically extremely experienced programmers, working on the largest
and most-challenging problems.  Sysadmins at sites using Lispms were
typically experienced AI programmers who also understood, at a fairly
deep level, quite a bit about how networks worked, and so forth, and
were administering their machines as part of being programmers.  This
was hardly an uneducated user population, and they -still- greatly
appreciated the long messages.)

o  You claim that I'm trying to eliminate all RTFM-type questions.
No, I'm not.  Manuals are important, and it's very difficult to learn
to use any complicated piece of software just by examining the error
messages it spits out.  I am, however, suggesting that we (at least)
take the error messages that most commonly cause users to seek help
from the list, and make them easier to understand, hence causing users
to not need to ask the list to often.  Note also that I previously
suggested that error messages point into the manual for further
information; this encourages users to read what they might not otherwise.

Let me make this latter point more strongly:

    I claim that finding the 10 error messages that most frequently cause
    users to ask questions on info-cvs, and making their error messages
    suggest what might be wrong, and where in the manual and on the web to
    look for help, will very dramatically reduce the number of FAQs on the
    list.  "What might be wrong" includes -why- the user is likely to
    be making the error, which is often one of incorrect (but entirely
    predictable) mindset.  

Note here that I'm talking about 10 error messages.  We could compute
which 10 those are simply by pulling all error messages out of CVS and
then running a tool over the archives that count how many times each
of them occurs.  I'll even run such a tool, if somebody else will take
the time to produce the list of messages.  (One trivial way might be
to simply run strings over the binary and use substrings of the
resulting strings, e.g., each substring up to the first % or somesuch.)

Making those 10 error messages say more might take someone an
afternoon.  If they get used in, then make sanity look for
substrings of the messages.  [One way would be to make the first line
of any modified message -exactly the same as it was in the current
release-, and add new information after that., and wrapper
scripts, could then simply use the first line as what they key off.  
Of course, the more-robust solution is to use error numbers---that's
what most RFC's use, e.g., RFC821/2 specify error numbers that
applications know won't change, but message text associated with
them that might.  If SMTP can do it, CVS can do it.]

Then we run a test.  We release a version with just those error
messages updated, and we see, over the new few months, how the
statistics go for users asking questions about those messages.
I'll bet you dollars to doughnuts that we see a marked reduction
in questions about those cases.  It won't be sudden, of course,
because not everyone will upgrade immediately.  But it should be
detectable if you plot the trends.

And with that, I'm outta here.  I'd be happy to suggest ways to
implement this idea, and to discuss the engineering trade-offs made
in implementing it.  I'd even be happy to spend some effort on some
patches, although I'm not necessarily volunteering to do -all- of the
work.  However, I will -not- respond to yet another scream from Greg
saying, "You must not do that!"  Life is too short.  If no one else
thinks that this is an idea worth pursuing, or if everyone else is so
cowed by the thought of having Greg yell at them for days that they're
unwilling to start, or if I'm told that no such patch will be accepted
to CVS, then it will die here.

If, on the other hand, others think that this is worthwhile, and are
willing to commit to helping out, regardless of how loudly Greg yells
at us that we are hastening the heat death of the universe, then maybe
we can actually make life easier for CVS' users and easier for those
who read this list, too.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]