Re: Clean up glibc version numbers in manual

[Roland McGrath <roland at hack dot frob dot com>]

> I've reverted that change, but I'd have thought it was the most obvious 
> part of the whole patch.

Thanks for being flexible.  I hope your misclassification of this
particular change as "obvious" makes you a little more circumspect about
doing things without allowing a reasonable period for discussion.  We're
not on the verge of a release or anything, and this was a change that did
not interact with any other pending change.  So it really does no harm to
allow several days for the key people to respond.

I'd like to encourage everyone with physical commit access to publish
fine-grained private branches often.  That's a good way to get pending
patches published with no possibility of transcription error, and it's
easier to see a current collection that way than by just looking at the
list traffic.  It also makes it trivial for someone else to complete the
approval cycle by doing the merge himself so you don't have to.

> Different changes have different levels of obviousness.  [...]

The usual definition of "obvious change" is typos in comments, trivial
syntax errors, and incontrovertible logic errors like an inverted test
(that's 100% clearly wrong).  That's the category of things which anyone
with physical access is free to commit.

The "pretty straightforward" category is one for which it's reasonable for
people who are general maintainers to do commits without waiting for a lot
of assent, though posting about it is a nice courtesy.

Anything that changes semantics or the substantive messages in public view
on behalf of the project (including authoritative-sounding bugzilla posts)
is never in either of those categories.

Changes to the source code can always be reverted, of course.  So don't
read me as foaming mad about a commit made too early.  But that's not the
case with public interactions such as categorical statements made on behalf
of the project in bugzilla or web pages.  Moreover, the things I've
objected to today were simply discourteous and anti-collaborative--and I'm
truly not a person easily offended.

> Since it's already the case that there are several automatically generated 
> .texi files in the manual, I will now propose that we eliminate the 
> UPDATED information altogether, as I did for GCC in 
> <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00206.html>, and generate 
> VERSION automatically so it is always the version number the manual came 
> with (and so the manual only claims to be for that version, not to be 
> *updated* for that version).

That's a reasonable proposal worthy of consideration for changing what we
put in the manual.  But it's a departure from what that bit of the manual
has meant in the past, and far, far away from the "obvious" category.


Thanks,
Roland