+1

cc interested or impacted parties: @adamwill @chrismurphy @kalev @kevin @mattdm @mohanboddu @pjones

-1
We should just enter Freeze as normal and allow the Blocker/Exception process to work as normal. If we don't have a signed UEFI shim by Go/No-Go, then we slip out a week. Rinse and repeat as needed. We can evaluate whether to pull additional changes in as they come up.

What @sgallagh says sounds reasonable…

I am inclined to vote -1 as well but let me ask this question: What is the benefit of doing this? Landing more updates just brings more potential breakage. Updates that fix stuff carefully can go in trough Freeze Exceptions. One delaying problem should not be an excuse to allow getting more delayed stuff in freely.

Landing more updates just brings more potential breakage. Updates that fix stuff carefully can go in trough Freeze Exceptions. One delaying problem should not be an excuse to allow getting more delayed stuff in freely.

The argument basically comes down to "we've decided that two weeks of freeze is sufficient for final, so if we know we're going to miss the target, we might as well let people land fixes". I suspect there are a lot of bug fixes that maintainers wouldn't bother with an FE for because they either don't know that they can or they don't feel like it's important enough. Letting them in with lower friction makes the live experience better and reduces the size of release-day updates to apply.

That said, it does mean we run the risk of more breakages, as you said. If we end up needing a longer freeze, that reduces pressure on QA and RelEng.

I think both arguments are very reasonable, and I don't have a strong preference for either one. I present the proposal as a neutral party. :smile:

Understood. -1 to the proposal.

-1 as well.

Though maybe the possibility of doing Freeze Exceptions could be more prominently featured, e.g. in the final freeze announcement, or the "release slip" announcement? Something like "if you still have a very important update for F34 lined up, file a Freeze Exception for it [here] for it to be considered to still be included in the F34 GA repositories and/or images".

-1 also let's use Freeze Exceptions :)

The problem here is, we have a looming old world/new world split coming. Install media will not work once the revocations happen.

The only reason it stopped being a FESCo blocker last cycle was because Ubuntu reverted its revocation of our PKI trust for the Secure Boot certificate. That revocation is going to happen this quarter, and it would be incredibly dumb for us to allow a Fedora release to go out with this breakage.

This needs to be a blocker because otherwise we might release with media that will not work on computers that get the revocation this quarter.

If we don't want to push back the freeze, then let's mark RH#1938630 as a FESCo blocker bug.

Blech, and now I realize we've got this marked as a blocker bug anyway. This is why I shouldn't comment right when I wake up in the morning and can't fully process things...

Yes, this must be a blocker. Currently, it is. I am fine if FESCo votes "this blocker cannot be waived without explicit FEESCo approval" etc.

However this ticket ask a different thing.

I also agree that the shim BZ must remain a blocker. I stand by my vote that we don't delay entry into Freeze just because this BZ might lead to a long Freeze.

If further information comes to light (such as the shim situation being delayed more than a couple weeks), we can always lift the Freeze later if we so choose.

@ngompa @zbyszek Do your latest comments imply a -1? If so, we can reject this ticket now, since we have four formal -1's already. It's already impossible for it to be approved via FastTrack.

Yeah, -1 for now.

With that, we have (+0, 0, -5).

Technically, our policy here would be for us to discuss this at a meeting, but with no votes in favor on record and the fact that our next meeting is actually after this would need to be in effect, I'm just going to close this as Rejected.