On Fri, Sep 18, 2020 at 11:02:26PM +0200, Miro Hrončok wrote: > Hello, > > 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)." > > https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle > > 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. > > https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#End_of_Life_.28EOL.29 > > 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 > > https://pagure.io/releng/issue/9759#comment-687136 > > 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 > possible." We used to say this in every single announcement about upcoming EOL releases. I guess it dropped from the template somehow? For example: https://lists.fedoraproject.org/archives/list/announce@xxxxxxxxxxxxxxxxxxxxxxx/thread/QCFQCN7JCRCNPD46UK5IAAJJHPRLYVK4/ "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 collection." 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 them now? > 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 EOL. > 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. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
