This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Clean up glibc version numbers in manual
On Tue, 21 Feb 2012, Roland McGrath wrote:
> The install.texi changes are good. But the manual version/date stamp
> change is not. Please revert that immediately, and refrain from any
> further instances of posting on a Sunday for supposed discussion and then
> committing before at least several whole workdays have passed to allow for
> some actual discussion.
I've reverted that change, but I'd have thought it was the most obvious
part of the whole patch.
Different changes have different levels of obviousness. Some are so
obvious that I think it makes sense for anyone just to check them in
without advance review. Some are pretty straightforward (or very similar
to other changes, etc.) and it makes sense to post them not so much for
review but to get other eyes on them in case someone spots a silly
mistake - in those cases I think waiting a day or two for any comments
makes sense. Some it's good to get someone to explicitly check, even if
you think they are straightforward - and some are more complicated and
could definitely do with an actual review (or, for whatever reason, known
to be more controversial).
Insisting on pre-commit review for obvious changes will just slow things
down unnecessarily.
> The text of the manual is certainly not updated with every release, and in
> fact parts of it are years out of date. Having the version stamp indicate
> the last time there was a real, conscious effort to update the text is
> useful to indicate to users approximately how out of date the current text is.
But it didn't indicate when there was last a real effort to update the
text - it indicated when the last (trivial) change had been made as of
when you fixed a bug (13153) someone had filed about the date being out of
date - and the date I changed it to also indicated a date on which changes
had indeed been made to the manual (namely, the install.texi changes).
It's only ever likely to indicate when someone last remembered to update
that date/version information, not anything useful about the manual, if we
follow your suggested practice.
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).
--
Joseph S. Myers
joseph@codesourcery.com