Re: EGLIBC (was: GNU C Library development and maintainers)

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 29 Mar 2012, Thomas Schwinge wrote:

> I'm sure you already have a scheme for keeping track of which changes you
> handled?  If others are to contribute here, then I think having something
> like the wiki page that is initially listing 174 commits and ticking them
> off one by one would be a suitable approach?

I don't think a list of 174 commits is useful here; original commits are 
mainly relevant for identifying the pieces that went into a change spread 
across multiple files, rather than for extracting patches to apply 
directly.  I'm thinking purely in terms of logical changes, not physical, 
and any wiki page should list logical areas, subdivided only when those 
divisions make logical sense, not physical.  At a first approximation, the 
division is into (cross build and test, option groups, miscellaneous) and 
each of those may be split up further; miscellaneous contains large pieces 
such as the e500 port (where I think the right approach for glibc will 
involve moving existing powerpc/fpu directories to subdirectories, similar 
to how m68k handles having multiple FPU variants) and configure 
pkgversion/bugurl support.

Since my starting point has been cross build and test I haven't tried to 
work out subdivisions of the other groups of changes.  Cross build and 
test of course divides into cross build and cross test, and since I've 
only been working on cross build that's the only area I've needed to 
remember state for.  Not yet complete from cross build are cross-rpcgen 
(in progress), bootstrap headers (in progress), changing -pie configure 
link test (which fails in bootstrap builds) to make PIEs always supported, 
cross-getconf, cross-localedef (of which cross-localedef is by far the 
most complicated and I think needs a major rework, involving localedef as 
a portable utility in a separate repository as part of the glibc project, 
using gnulib for portability).

Note that most of the changes that have gone in or are in progress have 
involved substantial reworks.  So what you want to list on a wiki page is 
not even logical areas of changes, it's the rationales for those changes, 
where the particular changes in EGLIBC are just one example of how to 
achieve a particular goal and when merging something you need (a) to 
explain and justify the goal and (b) to explain and justify the particular 
patch you propose as the right way to achieve that goal.  The point is not 
to merge particular patches, it is to achieve goals such as "the files 
installed by a bootstrap cross build are identical to those installed by a 
native build" or something similar for test results.  A bald assertion 
about merging cross-localedef is useless without the substantiating 
rationale for cross-localedef (which includes that localedef is a useful 
utility for building root filesystems, that its output depends on 
endianness and the alignment of uint32_t and that it uses enough memory 
that running it on the target during testing can be problematic for 
low-memory targets); you can't merge a patch without actually 
understanding the point of the patch (and in a couple of cases - backtrace 
tests, option groups - you should also take account of patches that have 
been discussed on the EGLIBC patches list without yet resulting in a 
commit).

-- 
Joseph S. Myers
joseph@codesourcery.com