Re: GNU C Library development and maintainers

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

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?

I intend to continue gradually submitting individual logical changes for 
inclusion in glibc (a process which has already started with various of 
the cross build / bootstrap changes; a couple of those changes that I have 
submitted, cross-rpcgen and changes relating to bootstrap headers, need 
revision to, respectively, use more generic makefile variables / rules and 
try to avoid libgcc_s / libgcc_eh being needed at all when building 
glibc).  Once cross-build / bootstrap changes are substantially done I 
expect to move on to cross-test changes.  Obviously it's up to the 
community whether a particular feature, or a particular approach to 
implementing that feature, is desirable in glibc.

It is of course often the case that the right approach to take for 
inclusion of a patch in glibc, now that such changes can be properly 
considered on their merits, is different from what was the best approach 
for an EGLIBC-local patch where it was desirable to reduce the cost of 
merges from glibc.

I hope Maxim may also help with some of this merge process.

I would certainly encourage people with changes in EGLIBC (that do not 
depend on other changes local to EGLIBC) to submit their own patches 
(again) for glibc - obviously, including any fixes to the patch that may 
have gone in EGLIBC since the original patch, and considering whether the 
original patch is actually the right approach when the cost of maintaining 
a local change is no longer an issue.  While I hope eventually to get to 
such miscellaneous changes, other people's changes that do not fall within 
general themes such as cross building and testing are not a current 
priority of mine for merging from EGLIBC so people merging their own 
changes will speed up the reunification.

Similarly, I would encourage maintainers of other distributor versions to 
submit their own local patches for consideration (as with the patches from 
EGLIBC, the right approach for merging into glibc may be different from 
the right approach for a local patch).

-- 
Joseph S. Myers
joseph@codesourcery.com