On Thu, 4 Mar 2021 at 03:01, Petr Pisar <ppisar@xxxxxxxxxx> wrote:
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.
I think we are all using different short hand definitions of what we want to happen and are seeing each other skip steps because of that. I am very guilty of this when saying what could happen in this scenario. The following is more detailed but still skips steps
1. Get a list of all packages which are branched for past EPEL releases.
2. Get a list of all 'active' packages in the latest Fedora active release (aka F33 if I were doing this today) versus prerelease where packages may still get orphaned dropped before final.
3. Compare the lists and filter out the ones remaining
4. Fork all those packages to a 'project' space so we don't pollute mainline.
5. Use a script on all the spec files to see what buildrequires/requires are needed on those packages.
6. Compare to existing pool of packages in ELN+already forked packages
7. Add forks of all the extra packages.
8. I would then probably rebuild all these in Copr or private system to get build order and find yet more 'missing' packages.
9. Put in fixes to spec files into the forks to make it work.
10. Put in a list for packages to be branched for 'ELN'
11. Keep up with 'active' package so your fork work is kept in line.
12. Do proper branch requests for the packages for 'ELN'
13. Merge Request Madness time
14. Start building in the real build system and find/fix problems missed in COPR private builds.
15. ...
16. Profit
--
Stephen J Smoogen.
_______________________________________________ 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
