On Wed, Oct 28, 2020 at 10:31 AM Ben Cotton <bcotton(a)redhat.com> wrote:
In yesterday's F33 emergency brake meeting[1], one of the issues that
came up is the short window for testing all of the different IoT
hardware. One way to reduce that effort (by extending the window) is
reducing the change set in the days before an RC. I don't know if it
would have helped in this particular case, as the kernel update that
caused some of the problems had security fixes, so we may have left it
in anyway. But the general idea is if we don't allow FEs all the way
up to the RC compose, we reduce the number of things that could break.
I don't know if I personally endorse this proposal or not, but in the
interests of open discussion, I am proposing a change to the freeze
exception process:
> Updates with an accepted Freeze Exceptions will not be included less than X hours
before the scheduled start of the Go/No-Go Meeting.
I pretty much already take this position the week before the go/no-go,
and then turn into pretty much a hard ass once we slip. There has to
be a very compelling reason to grant a freeze exception.
The kernel is difficult because stable updates can bring important
fixes as well as regressions, and that's just the way it is. The only
way around it is for Fedora's kernel to take an older stable kernel
and cherry pick some fixes, which will work for some things and not
others.
Are we able to allow different kernel versions for different archs?
What about different media? Or do they all get the same kernel
version? Pretty sure it's the latter which makes this harder.
--
Chris Murphy