PR#328: Update EOL date for F38 - rpms/fedora-release

rpms / fedora-release

#328 Update EOL date for F38

Merged a month ago by sgallagh. Opened 2 months ago by bcotton.

rpms/ bcotton/fedora-release f40-delay into f38

Update EOL date for F38

Ben Cotton • 2 months ago

eebab0e

fedora-release.spec

file modified

+1 -1

		`@@ -1,7 +1,7 @@`
		`%define release_name Thirty Eight`
		`%define is_rawhide 0`

		`- %define eol_date 2024-05-14`
		`+ %define eol_date 2024-05-21`

		`%define dist_version 38`
		`%define rhel_dist_version 10`

bcotton commented 2 months ago

Opening on behalf of @amoloney. F40 moved from early target date to target date #1.

sgallagh commented 2 months ago

Is it worth changing this now or should we wait until we have a "Go" decision?

bcotton commented 2 months ago

I think either way is fine. I did it now as an example since it was easier to show than to describe in the SOP. But there's little harm in waiting until go since, AFAIK, not much uses this field currently.

Changing it now would be the Most Correct™ choice, but it does require a trivial-but-nonzero amount of effort.

sgallagh commented 2 months ago

I don't think it makes sense to push out multiple updates to fedora-release in the event of multiple slips. It's not zero-cost: there's the build on the builders, impact to the mirrors, power consumed by everyone that downloads and installs it...

I think as long as it's extended prior to the currently-listed date, it should be fine.

bcotton commented 2 months ago

"Power consumed by everyone that downloads and installs it" is now my go-to for a "trivial-but-nonzero" cost. :-)

I'm fine with waiting until there's a go decision (or we get to target date 4 or so). In a future where, e.g., Gnome displays a "Oh no! You're reaching EOL soon, better do something about that" warning we'll want to shift to an "update the package after the no-go decision is reached" model.