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 left the time unspecified for now, because we should figure out if we like the general concept before we decide on the specific deadline. I was thinking something like 72 hours (3 days), which would put the deadline at 1700 UTC Monday. For simplicity's sake, I'm only sending this to the QA list now. If we have a general consensus on it being a good thing, we should distribute it more broadly before we adopt it. [1] https://meetbot.fedoraproject.org/fedora-meeting-2/2020-10-27/emergency-brakes-on-f33-release.2020-10-27-13.41.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ 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
