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: Status of backport at bugzilla


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.


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