#2591 Conditionally delay F34 Final Freeze if shim is delayed
Closed: Rejected 3 years ago by sgallagh. Opened 3 years ago by bcotton.

We have had some concerns raised that the signed shim to resolve BZ 1938630 will not be available in time for us to meet our scheduled release date. In response, several people have wondered if we could delay the start of the final freeze to allow maintainers to land more updates prior to the release.

To represent those concerns, I am proposing the following:

If we receive by 1400 UTC on 5 April a definitive and authoritative statement that an updated signed shim will not be available prior to 20 April, the start of the F34 Final Freeze will be delayed by a week to 13 April.

I picked 1400 UTC Monday as that's 24 hours before the scheduled start of the freeze. I picked 20 April because if it lands by then, we still have time to test it for our Target Date #1 milestone of 27 April.

The proposal is intentionally constructed to make keeping our existing schedule the default case. I would rather us have a longer-than-planned freeze than a shorter-than-planned freeze. This is probably moot because I think it's unlikely that anyone in a position to speak with authority on the shim schedule would be willing to publicly commit, but it's good to have an explicit decision just in case.

Tagging for fast track as the decision point is before the usual 7-day vote period.


-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.

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.

Metadata Update from @sgallagh:
- Issue close_status updated to: Rejected
- Issue status updated to: Closed (was: Open)

3 years ago

Log in to comment on this ticket.

Metadata