On Fri, Sep 18, 2020 at 11:02:26PM +0200, Miro Hrončok wrote:
As many of you know, Fedora has an EOL policy that roughly tl;drs to:
"Fedora N goes to End of Life 4 weeks after Fedora N+2 Final Release (GA)."
The document also says:
> Branches for new packages in the SCM are not allowed for distribution X after
> the Fedora X+2 release and new builds are no longer allowed.
I've recently discovered that for 10+ years, this was interpreted as:
1. at release of Fedora N+2, new dist-git branches for N are no longer allowed
2. 4 weeks later, Fedora N is EOL
When I was told this, I found it very surprising. Mostly because we usually
only ever announce the actual EOL deadline and I've never seen an
announcement that says: "From now on, no new packages for Fedora N are
We used to say this in every single announcement about upcoming EOL
releases. I guess it dropped from the template somehow?
"Fedora 21 will reach end of life on 2015-12-01, and no further updates
will be pushed out after that time. Additionally, with the recent
release of Fedora 23, no new packages will be added to the Fedora 21
I think we always did this until perhaps the last few?
Mohan: can you check the template you use for these? Or was Ben sending
But also because it doesn't really make sense to me. I can
imagine a case
when a bug in Fedora N can be fixed by adding a new package (for example
when we accidentally introduce a new dependency) and I don't understand why
Wouldn't that be caught in testing? but anyhow...
this should not be possible between Fedora N+2 release and Fedora N
Understandably many packagers might decide to WONTFIX at that point ("It's
going EOL in couple weeks anyway"), but if they choose to fix, we should
allow them to do so.
Similarly, before Fedora N is EOL, it is considered supported, and a need
to introduce a new package to a supported Fedora version IMHO is valid,
regardless of the approaching EOL.
The idea is that when a release has only 1 month left, we should really
avoid making changes to it. After it's EOL we can't fix anything we
break right before that, so we should be very conservative in changes.
The "one month" after the current release is a buffer time to allow
people who want to only upgrade every other release time to upgrade.
It shouldn't be used to push changes other than security or major
bugfixes. All IMHO of course.
So, my question is: Should we fix the document to describe the long standing
practice more understandably, or should we change the practice to allow new
dist-git branches until the actual EOL?
I think we should fix the document. :)
Additionally, we should fix/add it to the updates policy document... I
don't think it's there and it's really hard to find.