This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Clean up glibc version numbers in manual


On Tue, 21 Feb 2012, Roland McGrath wrote:

> Sorry, you're just wrong.  It is entirely reasonable to expect that I be
> consulted on core issues of glibc maintenance.  It is also entirely

I wouldn't call version numbers and dates in the manual "core issues of 
glibc maintenance".

> during which I don't respond to glibc issues.  There was no urgency in
> making any of these changes, and so no excuse for cutting short the usual
> collaborative process.

For fixing typos, and things that should obviously have been updated at 
the same time as something else but were forgotten, I think the right 
"usual collaborative process" is "commit and post and hope people will be 
less likely to forget those updates in future".  And that's what the 
libc.texinfo changes looked like to me - obvious forgotten updates in the 
context of the fact that this was just part of a whole series of patches 
fixing miscellaneous issues in the manual (where this particular patch 
seemed to be the best one to attach them to).

As for the install.texi changes (which you didn't object to), they had 
already received comment from Jeff Bailey (which it appears didn't reach 
the list because of an HTML part in his email, though my reply did reach 
the list, quoting all the substance of his reply) and from Marek Polacek 
interested in cleaning up parts of support for old compiler versions, and 
there were no objections to the changes themselves, just comments on other 
things that might be cleaned up as well.  And when there is interest in 
having one cleanup build on another cleanup - in ways such that the text 
of the two cleanup patches is likely to interact - I think that *does* 
make it more desirable to get the first cleanup in quickly, on the basis 
that things can be refined later if needed.

This was not a patch at all likely to cause any subtle breakage.  It had 
been tested more than some past manual patches had been (at one point 
"make pdf" was broken for a long time, I think years).  The installation 
documentation was extremely outdated and still needs a long series of 
patches to get it into reasonable shape.  Not everyone building and 
installing glibc is an expert - system integrators have to start as 
beginners at some point - and we can do a much better job of installation 
documentation through a series of patches all of which are straightforward 
but some conceivably have someone, somewhere concerned about some detail 
of how they are expressed.  (Where the patches do actually change the 
versions of tools accepted by configure, not just the manual, I do think 
in that case it is appropriate to wait longer for discussion and actual 
approval of the patch.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]