Fedora 41 EOL: whoops

Project Discussion
, , , ,
1

I noticed today that Fedora 41 was meant to go EOL yesterday.

Whoops.

Our esteemed @amoloney is off on maternity leave, and it seems we…didn’t manage to organize a smooth hand-off for this.

The EOL process includes sending Bugzilla warnings about the pending EOL two weeks before it happens, and that hasn’t been done, so I don’t think we should just go ahead and mark it EOL right now.

Here’s my proposal: we delay the EOL date to 2025-12-10, two weeks after it was supposed to be. (We’d have to update Bodhi and the schedule to reflect this; we should also send out a fedora-release update, I think, but we might be able to get away with skipping that). We run the Bugzilla EOL warning script ASAP. Then we do the rest of the EOL procedure as usual. This should include sending out a couple of announcements, though that doesn’t seem to be documented in the SOPs right now - we should probably fix that.

@jspaleta etc. WDYT? We should decide what to do promptly so we can start actually doing it. Since the US is in Thanksgiving and a lot of folks might not be around, if nobody has strong opinions against this in a day or two, I might just sort of start doing it.

15 Likes
2

Totally makes sense, I am dealing with signing fire right now, but I’ll send out the announcements regarding this in the mailing list. And, will try to make it uniform in all the places, bodhi says x, but the f41 schedule says y, and f43 says z, etc;
The
10th of December seems like an optimistic timeline.

3

Fedora 41 /etc/os-release says support ends 2025-12-15:

SUPPORT_END=2025-12-15

4

Well spotted. It looks like that was done as an estimate a long time ago and never updated once we had a more accurate F43 release date.

But since it’s there, we could go ahead and use that date, instead of Dec 10? Make Dec 15 the official EOL, update Bodhi and the schedule to say that, and send out the EOL warning mails on Dec 1…

3 Likes
5

So I looked into it a bit more, and I found the SOP, in the infra docs. We’re supposed to do a mail one week before EOL and then a mail on EOL day. It looks like we did that consistently for F38 and earlier but whiffed it for F39 and F40.

I do wonder if it might be better to move this communication task over to the program manager docs, and leave infra with just the infra tasks?

Anyway, for this cycle, if we’re going with Dec 15 as the EOL date, we should send the mail on Dec 8.

1 Like
6

I had actually noticed the lack of email
(while working on something completely
different), and then forgot to go back and
send any query to the lists as to asking
what (had not) happened.

So much for the theory that “given enough
eyeballs, all bugs are shallow” (I guess
sometimes the glasses fog over and the
brain occasionally gets distracted by a
different shiny (or maybe I am just
talking about me)).

Dec 15th sounds like a good plan.

1 Like
7

We really need to decide what is the source of truth here.

Currently there is:

fedora 41 fedora-release package:
https://src.fedoraproject.org/rpms/fedora-release/blob/f41/f/fedora-release.spec#_9
2025-12-15

fedora 41 schedule:
26 Fedora Linux 41 End of Life Wed 2025-11-19 Wed 2025-11-19 0

Fedora 43 schedule:
25 Fedora Linux 41 EOL auto closure Wed 2025-11-26 Wed 2025-11-26 0

fedora appstream-metadata:
https://src.fedoraproject.org/rpms/fedora-appstream-metadata/blob/f41/f/org.fedoraproject.fedora.metainfo.xml#_28
2025-11-26

bodhi:
https://bodhi.fedoraproject.org/releases/F41
End of Life 2025-11-26

Given that we pushed the fedora-release out with that date, I think
12-15 makes sense this time as well.

IMHO, we should stop including other releases in schedules… ie, drop
the note on the f43 schedule about anything to do with f41.

Also we should try and avoid eol date changes if we can.
I’d prefer if we just set it to one month after the ‘current’ target.
That way we could avoid changing it if we hit early or current,
and only have to change it if we miss.
See 2400401 – The os-release file EOL date does not match with Fedora Schedule

The bugzilla part is my fault. Aoife asked me about it before her
leave and I said I would find someone to do it… but then I got swamped
and didn’t. ;(

1 Like
8

Yeah, with the schedule changes and the fact that we missed the EOL reminder, it’d be good to clarify who should own this. I like Adam’s suggestion for moving it to the Fedora Program docs, and having the announcements handled by one group still feels cleaner, like it happens for some other tasks. I had this conversation with Aoifen already at the DevConf this year; it would be good to act on it.

For this release, I’ll send the email out myself. From the next one, I’ll open an issue so we can sort out a better long-term process. Sound good?

9

I think it would be better the other way around. Because it seems that F43 schedule was update with the slips, while who would update f41 schedule at that time. IOW if F41 schedule said look for precise F41 EOL into F43 schedule, that IMO would be acceptable

1 Like
10

This one takes Bodhi as source of truth.

11

I vote for doing this ASAP. The person doing most of the work should pick a date (it does not really matter which one) and start sending emails and updating things.

12

The EOL warning emails need to go out today if we’re doing Dec 15 as EOL. I was leaving it to @jnsamyak but I guess he didn’t get to it, so I’ll run it shortly. edit: I’m running it now. It takes a while! (I think I looked at making it batch the operations but Aoife and/or Ben didn’t want it…)

13

There is a little confusion, I think, according to our documentation, it said to send out a week before End Of Life :: Fedora Docs ;

But thank you for sending those out, I’ll take a look at what I missed.

14

That’s the reminder email to mailing lists, not the same thing. What I sent out was the Bugzilla notices. Re-reading that, I don’t know where I got “two weeks before EOL date” from, though, it actually says to send it out as soon as possible after the N+2 release, so we should have done it right after F43 went out. Oh, well, it’s done now.

15

Well, AIUI, the ultimate source of truth is the release date of Fedora N+2. By policy, the EOL date of Fedora N is four weeks after the release date of Fedora N+2. This is why I said we “forgot to EOL F41”: the policy EOL date for F41 should have been 2025-11-25, because that was four weeks from 2025-10-28, which was the release date of F43.

One of the major problems, though, is that we need to put some EOL date for Fedora N in the schedules and Bodhi and fedora-release long before we actually know the release date of Fedora N+2. So we have to guess. Frequently those guesses go out of sync with each other, and frequently they aren’t updated when we actually get the release date of Fedora N+2.

16

Well, AIUI, the ultimate source of truth is the release date of Fedora N+2. By policy, the EOL date of Fedora N is four weeks after the release date of Fedora N+2. This is why I said we “forgot to EOL F41”: the policy EOL date for F41 should have been 2025-11-25, because that was four weeks from 2025-10-28, which was the release date of F43.

What policy? :wink:

says “The Fedora Project releases a new version of Fedora Linux approximately
every six months and provides updated packages (maintenance) to these releases
for approximately 13 months.
This allows users to “skip a release” while still being able to always have a system that is still receiving updates.”

I can’t see anything off hand that really says ‘4 weeks from GA’
anywhere.

One of the major problems, though, is that we need to put some EOL date for Fedora N in the schedules and Bodhi and fedora-release long before we actually know the release date of Fedora N+2. So we have to guess. Frequently those guesses go out of sync with each other, and frequently they aren’t updated when we actually get the release date of Fedora N+2.

Yeah.

For that reason I think we should base the eol on a later milestone.
That way if we miss the first few we don’t have to change it.
Of course that leaves uses less time to migrate.

1 Like
17

I think it is better to set expectations for an earlier EOL date, and then exceed those expectations if necessary due to a schedule slip. If we initially set the EOL date later and then move it earlier, we are doing a disservice to our users by breaking a “promise” of sorts. People may make upgrade plans based on the date. Giving them more time in the case of a schedule slip is okay, but giving them less time than they had planned on is not okay. The initially set EOL date should only ever move later, never earlier.

2 Likes
18

I agree, one needs only look at what happened with CentOS 8 to see how users react to getting “rugpulled”, so to speak. If a release EOL is set at 13 months and it ends up being 14 months, nobody is going to really care as much, compared to if it was set for 13 months and ended up being only 12.

2 Likes
19

This one :wink:

“The N-2 release reaches End of Life four weeks after Fedora Linux N is released.”

As Groucho Marx so nearly said “These are my policies. If you don’t like them, I have others”…

2 Likes
20

I think it is better to set expectations for an earlier EOL date, and then exceed those expectations if necessary due to a schedule slip. If we initially set the EOL date later and then move it earlier, we are doing a disservice to our users by breaking a “promise” of sorts. People may make upgrade plans based on the date. Giving them more time in the case of a schedule slip is okay, but giving them less time than they had planned on is not okay. The initially set EOL date should only ever move later, never earlier.

I agree, one needs only look at what happened with CentOS 8 to see how users react to getting “rugpulled”, so to speak. If a release EOL is set at 13 months and it ends up being 14 months, nobody is going to really care as much, compared to if it was set for 13 months and ended up being only 12.

I guess I didn’t explain in enough detail my proposal. :slight_smile:

lets take f44 as an example.

from:

Early final target: Tue 2026-04-14
Final target: Tue 2026-04-21

I am suggesting we set f42 eol to 4 weeks after the final target. (
2026-05-12) Or even 5 weeks (2026-05-19).

Then if we release on the early date: nothing changes, eol is still
05-12 or 05-19).

If we release on the final target date: nothing changes, eol is still
05-12 or 05-19).

If we slip a week and release on 2026-04-28, then… if we set it on
2026-05-12 we might have to perhaps move it, if we set it to 2026-05-19,
it just stays the same.

If we slip more we would have to consider, but I think that should be a
fesco decision on what to do in those cases.

The idea is that we set a further out fixed date so we dont have to try
and change it every week and cause a mess. We would never make it
eariler.

1 Like