This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.21 - Call for bugzilla review.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 21 Jan 2015 01:18:39 +0000
- Subject: Re: glibc 2.21 - Call for bugzilla review.
- Authentication-results: sourceware.org; auth=none
- References: <54BEFA4B dot 5070503 at redhat dot com>
On Tue, 20 Jan 2015, Carlos O'Donell wrote:
> Maintainers,
Anyone, not just maintainers, can do Bugzilla triage - reviewing bugs
doesn't even need a copyright assignment.
> Please have a look through bugzilla for any bugs which
> we might be able to get fixed before 2.21 branches.
Even bugs that can't safely be fixed for the release can usefully be
progressed (if e.g. identified as duplicates or already fixed, or patches
pointed to, or identified as something we don't actually want to do, or
moved from the overflowing "libc" component to a more specific component).
We have 774 open bugs at present, and definitely need more Bugzilla work
(most bugs probably *will* need patches before they can be closed, but not
all).
> I suggest looking for simple bug fixes that don't
> add translations, new symbols, or require math ULP
> updates.
And where there seems to be nothing tricky about the question of whether
the change is actually desirable, or about the right way to fix it, or
whether fixing it might break applications. In some cases, a "simple" fix
can cause non-obvious problems; some changes are much safer than others.
(For any of the 47 "manual" bugs, there's very little risk of a fix
breaking anything. Fixing a subtle dynamic linker issue has much higher
risk even if it's a one-line fix. Many bugs are somewhere inbetween, e.g.
fixes to header definitions would usually be low risk, something like bug
17721 that only affect non-__GNUC__ compilers very low risk.)
--
Joseph S. Myers
joseph@codesourcery.com