Bug 2459249 - F44 EOL date out of sync with schedule
Summary: F44 EOL date out of sync with schedule
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: 44
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F44FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2026-04-17 19:02 UTC by Adam Williamson (Red Hat non-Fedora)
Modified: 2026-04-22 10:15 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson (Red Hat non-Fedora) 2026-04-17 19:02:38 UTC
Since we slipped the F44 release, the EOL date in /etc/os-release is now out of sync with https://fedorapeople.org/groups/schedule/f-44/f-44-key-tasks.html , which says "Fedora Linux 44 End of Life Wed 2027-06-02". /etc/os-release says 2027-05-19 . Bodhi also has the wrong date and needs updating.

The schedule also says "This is a changeable date and currently based off the Early Target Date", which I think is wrong - it should say "currently based off Final target date #2", I think. But I don't know if the date is wrong or the text is wrong or both, I forget the calculation.

Comment 1 Adam Williamson (Red Hat non-Fedora) 2026-04-17 19:03:12 UTC
Proposing for a Final FE as it'd be nice if the EOL date in the release images was as accurate as we can manage.

Comment 2 Stephen Gallagher 2026-04-17 19:53:32 UTC
Correct me if I'm wrong, but isn't the end date dependent upon the F46 schedule, not the F44 one? We don't slip out the EOL unless F46 slips, I thought.

Comment 3 Adam Williamson (Red Hat non-Fedora) 2026-04-17 20:07:41 UTC
the actual official final date is dependent on f46 release, yeah, but AIUI we have an estimate in the schedule that is (or should be?) based on the current release target. I think it assumes N+2 will come out exactly 52 weeks later and thus EOL for N will be 2 or 4 or whatever it is weeks after *that*?

Comment 4 Zbigniew Jędrzejewski-Szmek 2026-04-18 06:38:35 UTC
I thought we "absorb" the delay in the current release, so that subsequent releases do not shift. (Or we if didn't do that officially, I think we should. Releases should be at a stable wrt. the year.)

Comment 5 Adam Williamson (Red Hat non-Fedora) 2026-04-19 16:03:37 UTC
+3 in https://pagure.io/fedora-qa/blocker-review/issue/2119 , marking accepted.

Zbigniew, you might be right, I honestly don't know for sure.

Comment 6 Zbigniew Jędrzejewski-Szmek 2026-04-19 20:51:14 UTC
Looking at the schedule repo, I *think* we adjusted the end date upon delays.
E.g. https://pagure.io/fedora-pgm/schedule/c/6bd870c4e0800d944ae446da8370c1de95a400ba?branch=main
moved the FinishDate by two weeks. Other commits in that repo seem to do the same thing.

Nevertheless, I think we should abandon this practice and *not* shift the EOL date.
I think maintaining approximate the same-weeek-of-year-release-schedule is more important
than maintaining a fixed number of weeks in the lifetime of a release.

Thoughts?

Comment 7 Kamil Páral 2026-04-21 07:46:49 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #6)
> Nevertheless, I think we should abandon this practice and *not* shift the
> EOL date.
> I think maintaining approximate the same-weeek-of-year-release-schedule is
> more important
> than maintaining a fixed number of weeks in the lifetime of a release.

That seems like a saner practice and less of a maintenance burden for multiple parties involved. +1 to that.

Comment 8 Zbigniew Jędrzejewski-Szmek 2026-04-22 10:15:37 UTC
Opened https://pagure.io/fesco/issue/3597 to make this official.


Note You need to log in before you can comment on or make changes to this bug.