V Wed, Mar 03, 2021 at 09:46:52AM -0800, Kevin Fenzi napsal(a): > On Tue, Mar 02, 2021 at 01:04:56AM +0000, Davide Cavalca via devel wrote: > > Yes, the idea I had in mind was that each package that currenty has an > > "epel8" branch would also get an "epeln" branch that would be built > > against ELN. Then when ELN branches into CentOS Stream, the epeln > > branches could be used as the starting point for the corresponding EPEL > > release. > > So, the problem here is that it doesn't map to well to the rhel > timeframes. In Fedora, you just keep maintaining a package until you > need to retire/replace/rename it. In EPEL, there's 3 years between major > versions. A lot can happen in 3 years. For example, epel7 has Xfce 4.12 > in it, epel8 has Xfce 4.14, Fedora has Xfce 4.16. In each of those, some > components changed. There's some 4.12 packages that were dropped > entirely by 4.14, sometimes there's new ones. I wouldn't want to > maintain 4.14 in epel9, I would want it to be the latest one. > > All that said, we could change this and just mass branch everything and > leave it to maintainers to clean up/dead.package/retire things they no > longer wish to maintain. That pushes more work on them tho (as well as > more releng work to mass branch, build everything, etc). > It would be great to notify EPEL maintainers that there is a new EPEL 9 and that they could try packaging previous EPEL 8 packages for EPEL 9. Either as an e-mail message or a bug in Bugzilla. But branching EPEL 9 from EPEL 8 is not helpful. At least for me as a packager. The reason is, as Kevin wrote, that you want to base EPEL 9 on the latest (or very recent) Fedora sources. In my opinion the maintainers would end up with merging rahide to epel9 branch overrideding all epel8 commits with the risk of creaping unwanted epel8 tweaks there. I ground this claim on the fact the RHEL 9 is based on Fedora 34 where you have different packaging standards and package set than in RHEL 8. If relengs want to decrease a load of dist-git requests for epel9 branch, I would go with a compromise: Precreate epel9 branches with only the initial commit and enabling the package in Koji tag. -- Petr
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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
