This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Status of backport at bugzilla
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Allan McRae <allan at archlinux dot org>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org, OndÅej BÃlka <neleai at seznam dot cz>
- Date: Sun, 22 Sep 2013 20:12:16 -0400
- Subject: Re: Status of backport at bugzilla
- Authentication-results: sourceware.org; auth=none
- References: <20130921212153 dot GA10434 at domone dot kolej dot mff dot cuni dot cz> <523ED58A dot 6080506 at linux dot vnet dot ibm dot com> <523EDA37 dot 9050406 at archlinux dot org>
On 09/22/2013 07:53 AM, Allan McRae wrote:
> On 22/09/13 21:33, Adhemerval Zanella wrote:
>> On 21-09-2013 18:21, OndÅej BÃlka wrote:
>>> Hi, there are few 2.15 backports at bugzilla, they lose relevance with
>>> time so we should check their status.
In general I've been doing a terrible job of keeping up with
the backport requests. Once we realized this we decided that
we'd put more of the burden of work on the requester. We now
want backport requests to include the full patch or at least
comments like "Cherry pick applies cleanly, testing OK. etc.
etc."
Note that only bugs with keyword glibc_2.15 are valid
backport requests.
See: https://sourceware.org/glibc/wiki/Bugzilla%20Procedures
>>> I made list by searching bugzilla for 'backport'. What we will do with these?
Good question.
The release branch manager should close them or handle them.
Each bug should have an attached patch to backport.
If it doesn't have an attached patch then the requester hasn't done enough work for the RM.
The goal is make the RM ack the patch backport and then the work should be easy.
>>> 14343 [2.15] Function logb() in math.h produces incorrect results for small inputs 2013-03-20
- RESOLVED/WONTFIX, needs backported patch.
>>> 14033 [2.15] <bits/math-finite.h> references non-existing *l_finite symbols on double-only ports 2013-03-20
- RESOLVED/WONTFIX, needs backported patch.
>>> 14284 [2.15 backport] Fix invalid memory access in do_lookup_x. 2013-02-19
- Has a patch, should be pushed.
>>> 14599 [Linux/SPARC] libm_pic.a linking failure 2012-12-03
- Not a backport request. Is for 2.16.
>>> 14287 Backport RPC header patch from master 2012-12-03
- Has a patch, should be pushed.
>>> 13690 pthread_mutex_unlock potentially cause invalid access 2012-12-03
- Needs review.
>>> 13765 [2.15 backport] Make fmtmsg() function thread-safe 2012-12-03
- Needs a patch.
>>> 14668 [2.15 backport] Don't parse %s format argument as multibyte string 2012-12-03
- Has a patch, should be pushed.
>>> 13773 [2.15 backport] Call __fxstatat64 from faccessat() to avoid PLT in -Os builds 2012-06-28
- Told Chris to check his patch in.
>>> 13756 [2.15 backport] Sort objects before relocations 2012-06-28
- Should be checked in.
>>> 14041 getcontext@GLIBC_2.3.3 missing from libc 2012-06-27
- RESOLVED/WONTFIX. Needs a patch.
>>> 13902 [2.15 backport] Fix confstr use of local buffer outside its extent. 2012-06-27
- RESOLVED/WONTFIX. Needs a patch.
>>> 13755 [2.15 backport] Do not cache negative results in nscd if these are transient 2012-06-27
- RESOLVED/WONTFIX. Needs a patch.
>> I checked in glibc wiki and page and looks like we don't have any policy
>> regarding backport/mantainer policy. So I guess it will be a release maintainer
>> decision, in this case Carlos O'Donnell.
The release manager should close the branch and then close out the
backport requests.
>From my perspective 2.15 is dead since Fedora 17 (2.15-based) is now
dead, and there are no RHEL releases based on 2.15.
Comments?
>> Should we create a policy regarding how we maintain, hw many releases (maybe
>> based on time)?
>>
>
> It looks like there was no objections to the 2.16 and older branches
> being closed. See:
>
> https://sourceware.org/ml/libc-alpha/2013-09/msg00267.html
I need to act like a more responsible distribution maintainer and
upstream our distro patches. That way the upstream branches are
actually alive and working for distributions.
Cheers,
Carlos.