This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.21 - Call for bugzilla review.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]