This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 2.26 release blockers?
On 07/10/2017 04:12 PM, Joseph Myers wrote:
> On Mon, 10 Jul 2017, H.J. Lu wrote:
>
>> On Fri, Jun 30, 2017 at 1:44 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> Siddhesh,
>>>
>>> I added 2 release blockers:
>>> https://sourceware.org/glibc/wiki/Release/2.26#Release_blockers.3F
>>>
>>> The /etc/resolv.conf reloading and tcache are two important pieces of
>>> work that I'd like to see go out this release.
>>>
>>> What about everyone else?
>>>
>>> I assume the people that chimed in on the freeze thread need to decide
>>> if their work is blocker or desirable?
>>>
>>
>> I added
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=12189
>>
>> to release block for 2.26. This is a quite old bug. We should fix it for
>> 2.26.
>
> If a bug has been present and known in releases for years, without serious
> activity on it before the freeze, it can't possibly be a release blocker
> without some reason other changes have made it more serious. A blocker
> needs to have something to link it to the release it blocks (whether
> that's being a regression, being linked to active development before the
> freeze, or being an issue whose seriousness was only discovered since the
> last release).
>
> This is not an objection to a fix to this bug during the freeze should a
> patch be proposed that achieves consensus as a desirable change to glibc
> that is sufficiently safe on all architectures.
Agreed.
Please do not mark old bugs as a release blocker without meaingful
justification. The age of a bug is not good justification. The impact
on users, the benefit of the fix, would all be better justification.
--
Cheers,
Carlos.