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: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: 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 13:51:17 +0000
- 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> <569F82CA dot 20703 at linaro dot org>
On Wed, 20 Jan 2016, Adhemerval Zanella wrote:
> 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.
Obviously the sorts of bug fixes that get backported to release branches
after release should also be acceptable during the freeze (but maybe not
if it's a fix we'd want to leave for a while on master for stabilization
before backporting). Architecture-specific fixes should generally be
acceptable at the discretion of the architecture maintainers. We should
generally accept fixes for build breakage (including any build issues with
unreleased GCC and binutils versions, and including build failures for
testsuite code), and I think fixes for issues that show as testsuite
failures in some configurations but with extra care about the risks that
such fixes break things in other configurations.
--
Joseph S. Myers
joseph@codesourcery.com