glibc 2.19 release in 3 months. What blocks the release?

[Joseph S. Myers]

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