On Thu, Jan 28, 2021 at 03:05:16PM -0800, Troy Dawson wrote:
As we are getting closer to the F34 branching, which means we are
getting closer to CentOS 9 Stream, which will eventually be turned
into RHEL9 Beta, and then RHEL9 release. Now seems like a good time
to get ideas flowing about EPEL9.
I'm just throwing ideas around. Nothing I'm saying here is even close
to policy or a final plan. If people have other ideas, feel free to
say them.
epel8-next is getting closer and closer to being in place.
To me it seems logical to create a epel9-next, pointing at the CentOS
9 Stream (when it comes). It would need the same setting up as
epel8-next, all the steps would be the same other than the name and
where it points for it's repo.
We could also setup some type of signup board for if maintainers want
the EPEL Packaging SIG to automatically bring their packages over.
With epel9-next in place, and good set of EPEL9 packages in it, users
would be able to test RHEL9 much better in it's beta phase.
Also, it would take alot of pressure off when we start getting regular
EPEL9 setup. If it takes a month or two, people wouldn't be as
concerned, because they could always just grab the packages from
epel9-next.
I think that could be workable, but I'll toss out another proposal:
As soon as centos 9 stream exists, we create epel9-playground and allow
people to branch/add packages to it. Once rhel9 is GA, we setup epel9 as
usual and epel9-next and point epel9-next to build against stream and
playground to build against rhel9.
The advantages of that would be that epel9-playground is more rawhide
like... it would compose every night and there's no bodhi overhead.
Of course to be confusing we could just treat epel9-stream that way
until GA too I suppose.
In any case as soon as centos 9 stream is ready, I think it would indeed
be a great idea to start allowing epel builds against it one way or
another. :)
kevin