|| ||"Joseph S. Myers" <joseph-AT-codesourcery.com> |
|| ||Marek Polacek <polacek-AT-redhat.com> |
|| ||Re: GNU C Library development and maintainers |
|| ||Tue, 27 Mar 2012 10:39:01 +0000 (UTC)|
|| ||Mike Frysinger <vapier-AT-gentoo.org>, libc-alpha-AT-sourceware.org|
|| ||Article, Thread
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
to post comments)