This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.19 release in 3 months. What blocks the release?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Mike Frysinger <vapier at gentoo dot org>
- Date: Sat, 9 Nov 2013 17:16:12 +0000
- Subject: Re: glibc 2.19 release in 3 months. What blocks the release?
- Authentication-results: sourceware.org; auth=none
- References: <527DB6A6 dot 9050300 at redhat dot com> <20131109084609 dot GA7580 at domone>
On Sat, 9 Nov 2013, Ondrej Bilka wrote:
> On Fri, Nov 08, 2013 at 11:14:30PM -0500, Carlos O'Donell wrote:
> > Team,
> >
> > The 2.19 release page is up on the wiki:
> > https://sourceware.org/glibc/wiki/Release/2.19
> >
> > If you have something you think is a blocker for the
> > release please add it under Planning->Release blockers?
> >
> Mostly code review. there is a backlog of unreviewed patches and we get
> blockers mostly of latencies between patch replies.
What's the status on getting a patchwork installation set up for glibc so
unreviewed patches can be tracked better (Mike, you were talking to the
patchwork people as of June)? We've tried a wiki list of unreviewed
patches and it doesn't seem to work very well. We don't know if anyone
would monitor the list in patchwork (updating it for patches that have
been committed, rejected, or reviewed and now need changes and
resubmission) but it might be better than a wiki list. (I'd expect that
if this was set up, we'd ask people with outstanding patches to retest and
resubmit them - not just ping - so that those patches then got into the
patchwork list.)
Given the discussions of libc-alpha / libc-ports, I think it would be
reasonable for patchwork to track libc-alpha only. (Carlos, my offer
still stands to set up the wiki page describing issues for which
architecture maintainers need to update their ports, as a replacement for
people informing the libc-ports list when committing patches needing port
updates, if the bulk of the hppa issues listed at
<https://sourceware.org/ml/libc-ports/2013-09/msg00016.html> are addressed
first so I don't need to put lots of hppa-only issues on the page.)
Regarding features for 2.19, personally I've got in the changes I wanted
from EGLIBC - the remaining changes being listed at
<http://www.eglibc.org/archives/patches/msg01321.html> if anyone is
interested in merging any of them. How are other distributors doing with
eliminating local changes that don't need to be local? (I include gnulib,
for the files based on glibc sources, and the GNU Hurd glibc trees, among
distributors here.) Much the same applies for distribution bug reports -
if valid and applicable to current glibc sources, they should be entered
in glibc Bugzilla.
--
Joseph S. Myers
joseph@codesourcery.com