On Wed, Oct 28, 2020 at 3:48 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2020-10-28 at 12:29 -0400, Ben Cotton 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 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. > > I don't think I agree with this Big o'l same. > There is actually a policy that updates to fix blocker and FE issues > should include the minimal change necessary to fix the bug. We (mainly > I) have gotten progressively laxer about enforcing that in the last few > years, to the point where I rarely actually bother with it at all > except in super egregious cases. This is because we've kinda got a > better track record of updates not breaking stuff, and we have much > better test coverage than we used to. > I don't blame you one bit here. Part of the issue with this policy is enforcement. We have to trust maintainers to submit updates that will meet it (and we should trust our maintainers!), but it can be hard to tell until it's already in the compose. (In some cases, it's obvious, but not all). The policy is good guidance, but I don't think it can reasonably be an enforcement mechanism. The policy I proposed (as an idea, mind you, not an endorsement) would provide a very heavy-handed enforcement. It also takes the undue burden off of Adam to audit every FE. Many times, the FE is approved before the fix is available, so it's hard for voters to weigh in on whether or not the fix is reasonably-sized. -- 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
