But it makes sense to adjust it. Admittedly it doesn't happen to the extreme like Fedora 39 did, where we slipped into January before the EOL since we didn't release until November, but it is significant because it represents our actual EOL date.

Sorry, but I'm a bit confused. I thought the F44 EOL date shouldn't be determined by the F44 release date, but instead by the F46 release date (i.e. F46 GA + 4 weeks)?

But it makes sense to adjust it.

Please explain.

We have the following start dates:
Rawhide starts Fedora Linux 35 development Tue 2021-02-09
Rawhide starts Fedora Linux 37 development Tue 2022-02-08
Rawhide starts Fedora Linux 39 development Tue 2023-02-07
Rawhide starts Fedora Linux 41 development Tue 2024-02-13
Rawhide starts Fedora Linux 43 development Thu 2025-02-13
Rawhide starts Fedora Linux 45 development Tue 2026-02-03

The development schedule is fixed wrt. to the year. Users can expect that e.g. "F44 will be releases around week …", and I think it's also fine for them to know that "F42" will be EOL n days later.

Ugh, I just realized what I'm arguing. No, this makes sense. But I think it's because the practice is interpreted wrong. We are supposed to adjust the EOLs of the N-2 release when release date slips, not the upcoming release.

Exactly. The F44 EOL date set in /etc/os-release is aspirational (i.e. depends on F46 shipping on time). Updating it because of F44 slippage doesn't make sense IMO since that's not the date that determines the EOL date in the end.

OK. Amended proposal:

"The N release EOL date is initially set as the Early Target Date + 5 weeks of the N+2 release. If the N+2 release slips past the Final Target date #1, the N release EOL date is shifted in the same way."

"The N release EOL date is initially set as the Early Target Date + 5 weeks of the N+2 release. If the N+2 release slips past the Final Target date #1, the N release EOL date is shifted in the same way."

+1

I think maintaining approximate the same-week-of-year-release-schedule is more important
than maintaining a fixed number of weeks in the lifetime of a release.

+1 for that as well from the discussion in the bz.

Does that always works out to a four-week overlapping window where N and N+2 are both supported? If that's indeed the intention, why not just define the EOL date that way?

This almost comes out to this. The only difference is that if N+2 is released at Early Target Date, we do not adjust the EOL date of N, and there is a five week overlap. The motivation is twofold: since we almost never release on ETD, it gives users of N better estimate when it'll go EOL, and it also saves maintainers of fedora-release one update that'd almost always need to be made.

If that's the only difference between "always a four week overlap" and your current proposal, then I'm +1 - thanks for clarifying :)

+1 I am definitely in favor of less tweaking of it and pushing updates changing it.

OK. Amended proposal:

"The N release EOL date is initially set as the Early Target Date + 5 weeks of the N+2 release. If the N+2 release slips past the Final Target date #1, the N release EOL date is shifted in the same way."

+1 for this. So if we hit early target date or final target date #1 we don't need to adjust the EOL date of N-2, reducing the need for manual changes

+1

The proposal was voted in during today's FESCo meeting (meeting logs, starting at 17:08), and approved in-meeting, without relying on the fast-track process.

AGREED: The N release EOL date is initially set as the Early
Target Date + 5 weeks of the N+2 release. If the N+2 release slips
past the Final Target date #1, the N release EOL date is shifted in
the same way. (+7, 0, -0) (@decathorpe:fedora.im, 17:15:57)