fesco

#1750 Decide if EOL is one month after release, four weeks, or something else
Closed: Fixed Opened by mattdm.

Closed: Fixed
Reopen Issue

See this message which came into the Fedora Wiki mailing list.

The last item in the schedule
(https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Schedule_Methodology)
lists "End of Life" as "GA of next-but-one release plus one month",
however, a review of the "Unsupported Fedora Releases" table on
https://fedoraproject.org/wiki/End_of_life indicates the real end of
life should be listed as "GA of next-but-one release plus four weeks"

This is important for migration planning purposes and the information
presented in the wiki should be as precise and accurate as possible.
Could someone with privilledges to edit this page make the necessary
adjustment?

I think the actual practice has been four weeks to simply align with our general fixation with Tuesdays in the schedule. In other words, it's "one month, rounded down to the nearest Tuesday". That's not necessarily a bad thing, but I agree that we should be clear, and since EOL is really rather a big thing I'm bringing this to FESCo.

Options I see are:

  • Change documented policy and communication to match the four-week practice.
  • Ask release engineering to do the EOL by calendar months
  • Ask release engineering to round up instead of down (so, the fifth following Tuesday), so we'd have at least the promised month of final updates

Metadata Update from @maxamillion:
- Issue tagged with: meeting

I agree we should be more consistent - in BZ reminders, we use "Approximately 4 (four) weeks from now". So far, we do 4 weeks on Tuesday, from scheduling perspective, it's easier and predictable. On the other hand in marketing communication, one month (as real one month) looks better...

I'm leaning towards saying "one month" and making it "at least one month (i.e. round up to next Tuesday). I don't think the extra 4-5 days are going to cause much hardship for us, and more breathing room is nicer for users.

Ha, I was just about to suggest the very same thing as mattdm just did. +1 from me!

I have no preference. Realistically, EOL date doesn't really matter after the "No new packages" point in the schedule for end users. Updates filed after that point languish in bodhi with little karma anyway.
People that want to cling to an old release are going to continue to do so regardless of the distinction we're trying to make.

+1 to matt's proposal.

I am fine to prolong the EOL date from 4 to 5 weeks after Release+2 is made GA. The change in schedule and housekeeping tooling for Bugzilla is simple, but I do not know what needs to be done from RelEng point of view.

If this is approved by FESCo, should it be applied to F27 schedule (so the F25 EOL will already be 5 weeks after F27 is GA) ?

I would really rather keep the 4 weeks we currently have. the practical implications are not that huge however. once a relase goes GA the number of updates does go down quite a bit. we moved to 4 weeks purely because of simplicity, its easier to remeber that things happen on Tuesdays, We do the last push on the Monday. The difference between a month and 4 weeks is 2 or 3 days depending on the month

@ausil Since the practical implications are not huge from a releng side, is there any problem with "round up to 5"? I think that's the most user-friendly approach (and doesn't require a change in messaging), and if the cost in terms of effort is small it's still my preference.

This ticket was vigorously debated in last Friday's FESCo meeting. FESCo has decided that the use of "month" for marketing purposes is unnecessary. Let's say "four weeks" or "28 days" everywhere and have it done.

Metadata Update from @jsmith:
- Issue untagged with: meeting
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.