EGLIBC (was: GNU C Library development and maintainers)

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Tue, 27 Mar 2012 10:39:01 +0000 (UTC), "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> On Tue, 27 Mar 2012, Marek Polacek wrote:
> 
> > On Tue, Mar 27, 2012 at 12:13:15AM -0400, Mike Frysinger wrote:
> > > i hope this means we can eventually stitch the eglibc project back in
> > 
> > Yeah--what are future directions for eglibc?

Providing some numbers, based on a ``git svn'' mirror of EGLIBC.  There
have been 408 commits to trunk, of which 327 touch libc proper (excluding
those that only touch ports, linuxthreads, etc.), of which 174 touch
libc/ChangeLog.eglibc and thus (roughly) are what I'd call ``original
commits'' as opposed to those that are ``merge from glibc'' commits (but
these also might include additional changes, to align the merge to the
EGLIBC surroundings).  As always in software development, several of the
174 are fixes for earlier commits of the 174, and these should now be
consolidated.  Then, again several of these commits have by now been
obsoleted (for example, due to glibc code changes that got merged into
EGLIBC), or obsoleted in EGLIBC itself, or already cross-ported from
EGLIBC to glibc (and then obsoleted by the next merge from glibc to
EGLIBC).

This is still a number of changes that can be handled individually, and
this will probably work out fine for specific fixes (localized, that
don't span a lot of different files/infrastructure).  There can simply be
a list (in the wiki?) of all these commits, and we tick them off as we
cross-port them to glibc, or discard them as not suitable if so desired.

Another approach is to work by diff -ru glibc/ EGLIBC/ -- and work on
getting that towards exit code 0.  (Assuming that would be the goal,
which it might not be.)  The idea is that if an issue (generally
speaking) is now fixed in glibc that already had a different fix in
EGLIBC (but that variant of the fix that is not wanted for glibc), the
EGLIBC fix will be replaced with the glibc fix when Joseph is doing a
glibc to EGLIBC merge.  This approach will probably work out better for
logical changes that have seen several revisions (by means of several
commits over time), and that are spread all over the place; one prime
candidate being the cross-testing support (that touches a lot of
Makefiles, has seen several internal revisions due to enhancements, and
had to be adapted over time as merges from glibc added new tests).  For
such structural changes, my understanding is that EGLIBC has chosen
implementation methods that were easy to maintain (regarding following
merges from glibc), and that should now potentially be re-considered for
different implementation variants, case by case, as Joseph already has
explained in other emails.

Probably we will want to use a combination of both these approaches?


> I intend to continue gradually submitting individual logical changes for 
> inclusion in glibc (a process which has already started [...]

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?


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature