On 07/12/2017 06:10 AM, Jakub Jelinek wrote:
On Tue, Jul 11, 2017 at 09:36:28PM -0400, Carlos O'Donell wrote:
> On 07/06/2017 09:15 PM, Matthew Miller wrote:
> I encourage Jeff Law and Jakub Jelinek to review these schedules
> for compiler related issues.
> This is just a perfunctory review from the glibc perspective with
> regard to base ABI and API issues in this core runtime.
> 2018-01-10 MASS REBUILD
> - This date is ahead of the glibc release on 2018-02-01
> but after the 2018-01-01 ABI freeze date for glibc.
> Therefore you will be largely assured a stable ABI upon
> which to base Fedora, _but_ there is a vanishingly small
> chance you may need a mass rebuild or a targeted rebuild
> on 2018-02-01 if something has to be reverted.
2018-01-10 is way too early for a mass rebuild from GCC point of view,
even if we perform the test mass rebuild over the Christmas break,
there won't be enough time to analyze it and fix any GCC issues revealed
during that time.
Right. Optimistically, we'd let the test mass rebuild run
break giving the GCC team a nice pile of issues to look at in the start
of the new year. But even in that scenario I can't in good conscience
recommend Fedora start mass rebuilds on 01-10 -- it's just not enough
time to triage the issues from the mass rebuild and get them fixed.
01-25 is probably the earliest I'd recommend scheduling a mass rebuild
from GCC's point of view. Even that may be overly optimistic.
GCC bugfixing usually starts around November 15th and
needs some time before it can be fixed enough to use widely.
Moving the mass rebuild one week earlier than last time
is maybe doable, but not one month. And not rebuilding F27 with GCC 8
is a bad idea for both the compiler and Fedora.
FWIW I would like to see everything
in the GCC process shift earlier by
a couple weeks. I haven't had much success convincing folks to make
that shift though.
As for F29, there is no GCC release around that time, so from GCC POV the
schedule doesn't matter that much.
Right. The odd Fedora releases tend to just
pick up whatever the latest
point release of GCC is available. They don't tend to cause much work
or stress from a toolchain standpoint.