This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.23 --- Hard freeze starting
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 20 Jan 2016 10:51:22 -0200
- Subject: Re: glibc 2.23 --- Hard freeze starting
- Authentication-results: sourceware.org; auth=none
- References: <569D4A42 dot 7030006 at linaro dot org> <569D61E9 dot 1080501 at redhat dot com> <569D6754 dot 4080300 at redhat dot com> <569DD058 dot 6060500 at cs dot ucla dot edu> <569E7AE1 dot 1080201 at redhat dot com> <569E8894 dot 3040607 at linaro dot org> <alpine dot DEB dot 2 dot 10 dot 1601192147100 dot 27749 at digraph dot polyomino dot org dot uk> <20160119223132 dot GM14840 at vapier dot lan>
On 19-01-2016 20:31, Mike Frysinger wrote:
> On 19 Jan 2016 21:50, Joseph Myers wrote:
>> On Tue, 19 Jan 2016, Adhemerval Zanella wrote:
>>> My understanding is we set a long freeze period (usually a month) to exact
>>> iron out these kind of discussions. The freeze is exactly to limit discussion
>>> to a limited number of topics to avoid backlog overflow.
>>
>> I think the freeze is to allow plenty of time for architecture maintainers
>> to test for their architectures and fix problems found (so that it
>> shouldn't, for example, be a problem if some architecture maintainers are
>> away at the start of the freeze period) - and potentially for any extra
>> testing people wish to run while changes likely to invalidate it shouldn't
>> be going in. Not for adding new architecture-independent ABIs or other
>> changes that strongly indicate architecture maintainers should revalidate
>> (any new ABI means architecture maintainers should at least confirm the
>> ABI tests still pass).
>
> agreed. while it's annoying when your patchset missed another window, i
> don't think we should be allowing any changes like this w/out a very good
> reason. freezes are for stabilizing/testing/validating, not for slipping
> your pet projects in at the last minute (this is a generalization and is
> not directed at anyone in particular -- i'd point out that i have one or
> two patches that i wish would have made this release).
>
> it's not like we won't have another release in the future.
> -mike
Right, so then we need to enforce a policy of what is feasible to set as
release blocker and what should be moved to the next one. As you said,
architecture-independent ABI should not be a blocker, so the patches for
'Fix ABI for external copies of string function inlines on AArch64'
should be delay to 2.24.
So general bugfixes that has no consent/review until hard freeze I am
inclined to delay to next version. This applies to "[BZ #19329] Fix
race between tls allocation at thread creation and dlopen", which Carlos
has raised some concerns to apply on 2.23.
Finally we need to set what kind of last minute bugfixes should be allowed
or not. I noted some testcases fixes because of mantainers started to
tests and check on the failures. This potentially invalidate some
previous tests from other architectures, however they are still required
due the flawed test itself. I am usually inclined to accept such changes.