Help with 2.15.1 release.

Help with 2.15.1 release.

[Carlos O'Donell]

Community,

I need help with the 2.15.1 release, in particular backporting and testing take a lot of time.

I clearly wasn't thinking straight when I thought I could do it all myself.

In light of this less than startling revelation I'm looking for help.

The process I'd like to see should work similar to trunk, but with a little more tracking:

* Backport the patch to 2.15 branch.
* Test it.
* Post your results to the BZ issue for the backport request.
* I'll ACK as the branch release manager.
* You checkin the patch and close the issue.

The more we can parallelize the process the better right? :-)

Comments?

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026

Re: Help with 2.15.1 release.

[Joseph S. Myers]

For reference, the following bugs with glibc_2.15 keyword appear to have 
identified commits that need someone to backport and test them:

http://sourceware.org/bugzilla/show_bug.cgi?id=13754 [2.15 backport] Handle ARENA_TEST correctly
http://sourceware.org/bugzilla/show_bug.cgi?id=13755 [2.15 backport] Do not cache negative results in nscd if these are transient
http://sourceware.org/bugzilla/show_bug.cgi?id=13756 [2.15 backport] Sort objects before relocations
http://sourceware.org/bugzilla/show_bug.cgi?id=13765 [2.15 backport] Make fmtmsg() function thread-safe
http://sourceware.org/bugzilla/show_bug.cgi?id=13769 [2.15 backport] update core files with Tilera support
http://sourceware.org/bugzilla/show_bug.cgi?id=13770 [2.15 backport] Use <> brackets for not-cancel.h in  sysdeps/unix/sysv/linux/grantpt.c
http://sourceware.org/bugzilla/show_bug.cgi?id=13772 [2.15 backport] Use include/sys/epoll.h to provide libc_hidden_proto for epoll_pwait()
http://sourceware.org/bugzilla/show_bug.cgi?id=13773 [2.15 backport] Call __fxstatat64 from faccessat() to avoid PLT in -Os builds
http://sourceware.org/bugzilla/show_bug.cgi?id=13786 strcasecmp_l, strncasecmp_l act as strcmp for multiarch x86 (localedata/tst-xlocale1 fails)
http://sourceware.org/bugzilla/show_bug.cgi?id=13902 [2.15 backport] Fix confstr use of local buffer outside its extent.
http://sourceware.org/bugzilla/show_bug.cgi?id=13980 glibc-2.15 backport: fix typo in ppc32 code
http://sourceware.org/bugzilla/show_bug.cgi?id=14033 <bits/math-finite.h> references non-existing *l_finite symbols on double-only ports
http://sourceware.org/bugzilla/show_bug.cgi?id=14041 getcontext@GLIBC_2.3.3 missing from libc
http://sourceware.org/bugzilla/show_bug.cgi?id=14048 fmod() incorrectly returns NaN for (some?) denormalized inputs

The other five bugs with glibc_2.15 keyword do not appear to have specific 
commits identified, and some may not yet be fixed on master.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Help with 2.15.1 release.

[H.J. Lu]

On Thu, Jun 21, 2012 at 8:47 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> For reference, the following bugs with glibc_2.15 keyword appear to have
> identified commits that need someone to backport and test them:
>

Both binutils and GCC commits can update bugzilla automatically
if "PR xxx/xxxx" is in the commit message.  How hard to do the
something similar for glibc?

-- 
H.J.

Re: Help with 2.15.1 release.

[Roland McGrath]

It certainly was never the intent when we originally established the
release branch and release manager scheme that the release manager would
do the actual backporting work.  In fact, I was explicit at the time
that nobody should be doing things that way at all.  The idea of the
release branch is not just that it gets backports that "make sense".
The idea is that the purpose of releases is to have system-builders use
them in building packaged systems.  Those folks usually apply various
patches to their releases, including backports of trunk bug fixes that
they've deemed worthwhile for the users of their stable system releases
to have.  In the original conception, the release branch was a place for
backport patches that multiple system-builders were already using and
agreed were a good fix.  The release manager's role, then, is to collect
candidate patches from people who are already using and testing them,
verify that they are only backports consistent with the behavior of
changes already on the trunk, judge that they are stable and noninvasive
enough to to be appropriate for the particular release branch, and lead
a consensus decision on when the branch has collected enough fixes that
it's a good time to make a point release.  This involves a lot of scut
work fiddling bugzilla, juggling git stuff, coordinating with other
hackers, making tarballs, sending announcements, etc., but not very much
actual coding at all.

IMHO, anyone who has marked a bug requesting a 2.15 backport and has not
already done the backport, tested the code, exposed their users to it,
and reported all those details, is not holding up their end and you as
release manager should either harangue them or feel free to ignore them.


Thanks,
Roland

Re: Help with 2.15.1 release.

[Carlos O'Donell]

On 6/21/2012 1:09 PM, Roland McGrath wrote:
> It certainly was never the intent when we originally established the
> release branch and release manager scheme that the release manager would
> do the actual backporting work.  In fact, I was explicit at the time
> that nobody should be doing things that way at all.  The idea of the
> release branch is not just that it gets backports that "make sense".
> The idea is that the purpose of releases is to have system-builders use
> them in building packaged systems.  Those folks usually apply various
> patches to their releases, including backports of trunk bug fixes that
> they've deemed worthwhile for the users of their stable system releases
> to have.  In the original conception, the release branch was a place for
> backport patches that multiple system-builders were already using and
> agreed were a good fix.  The release manager's role, then, is to collect
> candidate patches from people who are already using and testing them,
> verify that they are only backports consistent with the behavior of
> changes already on the trunk, judge that they are stable and noninvasive
> enough to to be appropriate for the particular release branch, and lead
> a consensus decision on when the branch has collected enough fixes that
> it's a good time to make a point release.  This involves a lot of scut
> work fiddling bugzilla, juggling git stuff, coordinating with other
> hackers, making tarballs, sending announcements, etc., but not very much
> actual coding at all.
> 
> IMHO, anyone who has marked a bug requesting a 2.15 backport and has not
> already done the backport, tested the code, exposed their users to it,
> and reported all those details, is not holding up their end and you as
> release manager should either harangue them or feel free to ignore them.

Thanks Roland. Yes I realized that the way I'd written up the policy
and the way I behaved had painted me into a corner.

Cheers,
Carlos.

Re: Help with 2.15.1 release.

[Chris Metcalf]

On 6/21/2012 10:19 AM, Carlos O'Donell wrote:
> Community,
>
> I need help with the 2.15.1 release, in particular backporting and testing take a lot of time.
>
> I clearly wasn't thinking straight when I thought I could do it all myself.
>
> In light of this less than startling revelation I'm looking for help.
>
> The process I'd like to see should work similar to trunk, but with a little more tracking:
>
> * Backport the patch to 2.15 branch.
> * Test it.
> * Post your results to the BZ issue for the backport request.

I have tested all the 2.15 backport bugs relevant to tile on both tilepro
and tilegx64/tilegx32.  I updated bugs 13769, 13770, and 13772 with this
status.  I also took the liberty of filing another bug (14279) and marking
it as OK too - this tracks the handful of correctness fixes that have gone
into 2.16 and should go into 2.15.1 as well.  (I didn't transition the bugs
to RESOLVED since I assumed that should wait until the commits land on the
branch.)

> * I'll ACK as the branch release manager.
> * You checkin the patch and close the issue.

I assume you mean push to master?  Or would you prefer me to put this on a
branch that you can pull?

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

Re: Help with 2.15.1 release.

[Carlos O'Donell]

On 6/21/2012 1:36 PM, Chris Metcalf wrote:
> On 6/21/2012 10:19 AM, Carlos O'Donell wrote:
>> Community,
>>
>> I need help with the 2.15.1 release, in particular backporting and testing take a lot of time.
>>
>> I clearly wasn't thinking straight when I thought I could do it all myself.
>>
>> In light of this less than startling revelation I'm looking for help.
>>
>> The process I'd like to see should work similar to trunk, but with a little more tracking:
>>
>> * Backport the patch to 2.15 branch.
>> * Test it.
>> * Post your results to the BZ issue for the backport request.
> 
> I have tested all the 2.15 backport bugs relevant to tile on both tilepro
> and tilegx64/tilegx32.  I updated bugs 13769, 13770, and 13772 with this
> status.  I also took the liberty of filing another bug (14279) and marking
> it as OK too - this tracks the handful of correctness fixes that have gone
> into 2.16 and should go into 2.15.1 as well.  (I didn't transition the bugs
> to RESOLVED since I assumed that should wait until the commits land on the
> branch.)

Please attach the patch to the BZ, I'll review that, and ACK.

>> * I'll ACK as the branch release manager.
>> * You checkin the patch and close the issue.
> 
> I assume you mean push to master?  Or would you prefer me to put this on a
> branch that you can pull?
> 

Yes, I mean push to refs/heads/release/2.15/master.

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026

Re: Help with 2.15.1 release.

[Chris Metcalf]

On 6/21/2012 1:48 PM, Carlos O'Donell wrote:
> On 6/21/2012 1:36 PM, Chris Metcalf wrote:
>> On 6/21/2012 10:19 AM, Carlos O'Donell wrote:
>>> Community,
>>>
>>> I need help with the 2.15.1 release, in particular backporting and testing take a lot of time.
>>>
>>> I clearly wasn't thinking straight when I thought I could do it all myself.
>>>
>>> In light of this less than startling revelation I'm looking for help.
>>>
>>> The process I'd like to see should work similar to trunk, but with a little more tracking:
>>>
>>> * Backport the patch to 2.15 branch.
>>> * Test it.
>>> * Post your results to the BZ issue for the backport request.
>> I have tested all the 2.15 backport bugs relevant to tile on both tilepro
>> and tilegx64/tilegx32.  I updated bugs 13769, 13770, and 13772 with this
>> status.  I also took the liberty of filing another bug (14279) and marking
>> it as OK too - this tracks the handful of correctness fixes that have gone
>> into 2.16 and should go into 2.15.1 as well.  (I didn't transition the bugs
>> to RESOLVED since I assumed that should wait until the commits land on the
>> branch.)
> Please attach the patch to the BZ, I'll review that, and ACK.

All four bugs now have the patches as attachments.  Thanks!

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com