This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Distribution merge status Feb 2014
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Sun, 2 Feb 2014 18:15:48 +0000
- Subject: Distribution merge status Feb 2014
- Authentication-results: sourceware.org; auth=none
As of 2.19, all the changes from EGLIBC that I wanted to get merged into
glibc have been merged and I will cease maintaining EGLIBC trunk after
2.19 is out. (A few changes - items 2 to 10 at
<http://www.eglibc.org/archives/patches/msg01321.html> - were dropped
rather than making an attempt to merge them to glibc.)
How are other distributors doing on merging their changes to glibc as far
as relevant? That is, about how many changes (in principle relevant to
glibc rather than only making sense at all in the distribution context)
are yet to be merged and when might you expect to have them
submitted/merged by? Specifically:
* gnulib (where I think the aim should be for identical sources of shared
files in both locations, except for gnulib's automatic changes to license
headers and replacement of TABs by spaces). Note that for portability
fixes - any change that won't affect the code as used in glibc - review
for glibc should basically be about style rather than the substance of the
code not being used in glibc, as per
<https://sourceware.org/ml/libc-alpha/2013-10/msg00025.html>.
* GNU Hurd (where the aim should be for everything to be in mainline glibc
so distributors don't need to apply any unmerged patches, or backport
anything beyond bugfixes such as go on the release branches anyway).
* GNU/Linux distributions.
(The same applies to distribution bug trackers - if a distribution bug
describes a bug present in current git, getting it into glibc Bugzilla is
useful. But I'm thinking first in terms of resolving the backlogs of
unmerged patches.)
--
Joseph S. Myers
joseph@codesourcery.com