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.
Troy
On Thu, Jan 28, 2021 at 03:05:16PM -0800, Troy Dawson wrote:
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.
Makes sense to me!
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
On Thu, 2021-01-28 at 15:15 -0800, Kevin Fenzi wrote:
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.
epel9-playground acting first as a "Rawhide" for c9s pre-RHEL9 GA and then as a playground for RHEL9 could be a bit confusing?
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.
Right, using epel9-next but with no Bodhi gating until GA seems like a nice idea. To add another variant to this: we can also start enabling Bodhi but with time-to-stable set to 3 days (like Fedora betas) once RHEL 9 is in beta? i.e. "we think c9s should have stabilized enough by now that we can start gating EPEL packages targeting it".
Best regards,
On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote:
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.
Do you know what CentOS 9 Stream will look like between its first availability and RHEL 9 GA? I worry that there will surface RHEL 9.1 changes. Then switching epel9-playground from CentOS 9 Stream to RHEL 9 could manifest incompatibilities as the build root would regress.
-- Petr
On Fri, Jan 29, 2021 at 2:29 AM Petr Pisar ppisar@redhat.com wrote:
On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote:
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.
Do you know what CentOS 9 Stream will look like between its first availability and RHEL 9 GA? I worry that there will surface RHEL 9.1 changes. Then switching epel9-playground from CentOS 9 Stream to RHEL 9 could manifest incompatibilities as the build root would regress.
Very good question Petr, and thanks for asking it. I asked internally about this. There will be a set time [1] when RHEL 9.0.0 release will be branched, and all the final stabilizing stuff will happen internally. At that point, CentOS 9 Stream will be on the 9.1.0 release, and any changes to it will not be in the 9.0.0 GA. I don't know when that point in time is, I haven't figured it out yet. But my educated guess is 3 months before GA, if I'm wrong, then I don't think more than 6 months before GA.
So, that gives us something to consider. Do we think that 3 to 6 months of possible changes will affect us too much? Troy
[1] - I wasn't given a date, just X weeks into the schedule.
On Fri, Jan 29, 2021 at 01:46:56PM -0800, Troy Dawson wrote:
On Fri, Jan 29, 2021 at 2:29 AM Petr Pisar ppisar@redhat.com wrote:
On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote:
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.
Do you know what CentOS 9 Stream will look like between its first availability and RHEL 9 GA? I worry that there will surface RHEL 9.1 changes. Then switching epel9-playground from CentOS 9 Stream to RHEL 9 could manifest incompatibilities as the build root would regress.
To be clear if the question was directed at me: I have no idea. ;)
Very good question Petr, and thanks for asking it. I asked internally about this. There will be a set time [1] when RHEL 9.0.0 release will be branched, and all the final stabilizing stuff will happen internally. At that point, CentOS 9 Stream will be on the 9.1.0 release, and any changes to it will not be in the 9.0.0 GA. I don't know when that point in time is, I haven't figured it out yet. But my educated guess is 3 months before GA, if I'm wrong, then I don't think more than 6 months before GA.
So, that gives us something to consider. Do we think that 3 to 6 months of possible changes will affect us too much? Troy
[1] - I wasn't given a date, just X weeks into the schedule.
We talked about this in the meeting yesterday some.
Pondering on it I think the best was forward would be:
* as soon as centos 9 stream exists and is consumable, we setup things and start allowing epel9-next branches (only) for things. We could do this as we plan for epel8-next (ie, bodhi, updates/updates-testing) or we could decide thats too much overhead and just do a daily compose of everything. The first option would be more up-front work, but then we don't have to change it later.
* as soon as rhel9 GA is available and consumable, we setup things and start allowing epel9 branches. We also send a note to all 'epel9-next' maintainers that epel9 is available and that they should request that and build there. If we did epel9-next as a 'rawhide style daily compose' we would switch it to bodhi/updates-testing then.
I'm not sure what to do about rhel9-beta. My first thought is to ignore it and tell people to use epel9-next with it, and consider following stream to get updates.
As for epel9-playground... I'm kind of coming to the idea that it's not that useful really and we shouldn't make one for 9.
SO, I guess this is all just the orig proposal. ;)
kevin
epel-devel@lists.fedoraproject.org