On Wed, Oct 28, 2020 at 10:31 AM Ben Cotton <bcotton@xxxxxxxxxx> 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 _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
