In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
* PLAN A Plan A is basically what we've been working towards for the past couple of months. - launch epel9-next now-ish (ideally aligned with c9s launch promotion) - After RHEL9 goes GA -- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros: - epel9-next and epel9 are only set up once, and not changed - ready to go now
** Plan A Cons: - complexity and added work of mass branch and mass rebuild - mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages) - epel9 not available at rhel9 ga - confusing messaging to packagers: -- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed - confusing messaging to users: -- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
* PLAN B - epel9-next stays the way it is currently setup. - Setup epel9 using RHEL9 Beta for the buildroot. -- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB - Launch epel9 and epel9-next together (In 1-2 weeks). - When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA
** Plan B Pros: - simple messaging to packagers: -- epel9 is the primary target, use epel9-next only when needed (same as epel8-next) - simple messaging to users: -- use epel9 everywhere (epel-next-release is a recommends on c9s) - no mass branching - no mass rebuild - No confusion from using the full CentOS Stream buildroot -- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons: - potential for large divergence between rhel9 beta and ga - changing our messaging right before the launch
* PLAN C - epel9-next stays the way it is currently setup. - setup up epel9 using c9s for the buildroot -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB - freeze epel9 buildroot before c9s switches to 9.1 content - launch epel9 and epel9-next together (1-2 weeks) - switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros: - simple messaging to packagers: -- epel9 is the primary target, use epel9-next only when needed (same as epel8-next) - simple messaging to users: -- use epel9 everywhere (epel-next-release is a recommends on c9s) - no mass branching - no mass rebuild - No confusion from using the full CentOS Stream buildroot -- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons: - potential infrastructure complexity of freezing the epel9 buildroot - changing our messaging right before the launch
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
Troy
On Thu, Nov 18, 2021 at 2:32 PM Troy Dawson tdawson@redhat.com wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
I like Plan C, personally. Especially given how easy it is to work with the RHEL maintainers with CentOS Stream 9 right now, when it's easy to get content from buildroot added to CRB. Post-GA is way more painful and slower. There's also the benefit of on-ramping folks using the RHEL 9 beta too.
I've been testing some builds for an EPEL-like thing for some dev work effectively by doing Plan C, and it has been working fantastically well.
So I'd love to see Plan C executed ASAP, so I can move that work into EPEL proper.
On Thu, Nov 18, 2021 at 11:31:42AM -0800, Troy Dawson wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot
differences (unshipped devel packages)
So, I had this question: How do we handle this mass rebuild? we branch everything in epel9-next into epel9 and build it... do we bypass bodhi for the intial population of packages?
- epel9 not available at rhel9 ga
True, but it could be pretty soon if we really pushed it and had everything ready to go. It's not going to be like rhel8 where we had to do all sorts of things. It should just be build, compose, go.
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled
Dropping this would drop some of the confusion. ;)
-- use epel9 primarily once it exists
I prefer this plan. It's more clear, it does what we said we were gonna do. :)
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to
RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
So, this would require packagers to request epel9 branches before GA right? this would then drop the plan to branch from epel9-next?
This would require us to sync the beta and any errata.
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
Do we know for sure when this is?
It would also mean we would be stuck for updates during that window between switch and GA.
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
Another con: breaks a foundational promise of EPEL. "builds against rhel". Now, of course we don't have that said anywhere, but some people really really like that it's built against RHEL and will be quite upset when it's built against stream. :( Not to say we can't do it, but I bet there will be yelling.
We already sync stream, but this will require us to 'freeze' it, which could be tricky.
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
I like A. ;)
I think B is risky because of the possible changes between beta and ga, and I think C is breaking the 'we build against rhel' implied promise as well as leaving a window with no security updates between branching and GA.
kevin
On Thu, Nov 18, 2021 at 3:12 PM Kevin Fenzi kevin@scrye.com wrote:
..snip...
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot
differences (unshipped devel packages)
So, I had this question: How do we handle this mass rebuild? we branch everything in epel9-next into epel9 and build it... do we bypass bodhi for the intial population of packages?
Yes, at the time of rhel 9 ga, the plan is to create an epel9 branch from epel9-next branch (that are active) and rebuild them against rhel 9 ga buildroot. We could bypass bodhi or we can create a single update in bodhi, all though I like the testing before dumping, in this case I prefer bypassing bodhi just because we dont want to hold off all the builds if there is an issue with one build.
...snip...
On Thu, Nov 18, 2021 at 2:14 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Nov 18, 2021 at 11:31:42AM -0800, Troy Dawson wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot
differences (unshipped devel packages)
So, I had this question: How do we handle this mass rebuild? we branch everything in epel9-next into epel9 and build it... do we bypass bodhi for the intial population of packages?
- epel9 not available at rhel9 ga
True, but it could be pretty soon if we really pushed it and had everything ready to go. It's not going to be like rhel8 where we had to do all sorts of things. It should just be build, compose, go.
No doubt it will be ready much faster than epel8. But many folks I'm talking to have a strong desire for it to be ready day 1. I've pushed back on them up to this point, but that pressure has me wondering if we can come up with a better plan.
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled
Dropping this would drop some of the confusion. ;)
Exactly. The original plan made sense to all of us on the committee, but as I communicate that plan to packagers and other stakeholders, I'm realizing it's more confusing than we initially realized.
-- use epel9 primarily once it exists
I prefer this plan. It's more clear, it does what we said we were gonna do. :)
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to
RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
So, this would require packagers to request epel9 branches before GA right? this would then drop the plan to branch from epel9-next?
Yes, it would make it match how epel8/epel8-next works now, regardless of being pre-GA right now.
This would require us to sync the beta and any errata.
Yes, that would be the what this plan requires from the infra team.
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
Do we know for sure when this is?
It was always very clear with c8s when we cut the content over. For c9s I have no doubt we can get good guidance on this from our CPE teammates.
It would also mean we would be stuck for updates during that window between switch and GA.
I don't see a significant risk here. It would only be approximately 1-2 months. Soname changes are the biggest concern, and that is extremely unlikely that close to the GA release. Security changes don't change the soname, and dynamically linked packages don't need to be rebuilt. Staticly linked packages are another story, but those are fairly rare in EPEL due to the massive dependency burden of golang and rust.
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
Another con: breaks a foundational promise of EPEL. "builds against rhel". Now, of course we don't have that said anywhere, but some people really really like that it's built against RHEL and will be quite upset when it's built against stream. :( Not to say we can't do it, but I bet there will be yelling.
I see an easy pivot there of "built against RHEL, once it reaches GA release". I think far more people would be happy about having day 1 EPEL9 packages than would be upset about this slight shift.
We already sync stream, but this will require us to 'freeze' it, which could be tricky.
I'm specifically interested in how difficult this would be from the infra perspective. That is definitely a factor.
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
I like A. ;)
I think B is risky because of the possible changes between beta and ga, and I think C is breaking the 'we build against rhel' implied promise as well as leaving a window with no security updates between branching and GA.
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Nov 18, 2021 at 2:32 PM Troy Dawson tdawson@redhat.com wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
I like this plan as it is my brain child, it is what we have been communicating and planning, it doesn't really diverge from what EPEL has been. But... (see my opinion on Plan B)
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
Maybe we can run a mass rebuild to capture all the differences between rhel9 beta and rhel9 ga. That would solve one of the con's below.
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
I didn't see one question answered here, the maintainer has to request both epel9 and epel9-next branch or up until rhel9 ga if a maintainer requests epel9 branch they will also get epel9-next branch (like it was set up for epel8-playground). If we run a mass rebuild, then it wont be much different from that of Plan A, except there might be a few (or more, depending on delta) packages that will work on rhel9 ga. So, I am not against this idea as well. One thing I would like to mention here is, even if we can setup this way since rhel 9 beta is out, we cannot do that same thing during rhel10 time as we might setup epel10-next way in advance before the rhel10 beta. We cannot keep this plan consistent going further.
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
I can see how its advantageous, but I dont like this plan, since there are some uncertainties, we dont really know when c9s will start pointing to rhel 9.1, we can only guestimate currently. Even if we know for sure, we have to ask centos stream folks to freeze their work until we sort out things on our side. And what if the package versions changed in rhel9 ga, because they found an issue in that build.
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
I am okay with either plan A or plan B.
Troy
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Nov 18, 2021 at 1:04 PM Mohan Boddu mboddu@bhujji.com wrote:
On Thu, Nov 18, 2021 at 2:32 PM Troy Dawson tdawson@redhat.com wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new
proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals.
Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple
of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot
differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when
needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
I like this plan as it is my brain child, it is what we have been communicating and planning, it doesn't really diverge from what EPEL has been. But... (see my opinion on Plan B)
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to
RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as
epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
Maybe we can run a mass rebuild to capture all the differences between rhel9 beta and rhel9 ga. That would solve one of the con's below.
For Plan B or C, doing a mass rebuild doesn't feel right. It should be fairly easy to tell if a package is going to install or not. The packages only need to be rebuilt if they cannot be installed.
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
I didn't see one question answered here, the maintainer has to request both epel9 and epel9-next branch or up until rhel9 ga if a maintainer requests epel9 branch they will also get epel9-next branch (like it was set up for epel8-playground).
If you request an epel9 branch, you do not automatically get an epel9-next branch. We don't do that for epel8, nor do we do it for epel9. And yes, I've tested it.
If we run a mass rebuild, then it wont be much different from that of Plan A, except there might be a few (or more, depending on delta) packages that will work on rhel9 ga.
So, I am not against this idea as well. One thing I would like to
mention here is, even if we can setup this way since rhel 9 beta is out, we cannot do that same thing during rhel10 time as we might setup epel10-next way in advance before the rhel10 beta. We cannot keep this plan consistent going further.
You have a good point there about not being able to do this for epel10.
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as
epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
I can see how its advantageous, but I dont like this plan, since there are some uncertainties, we dont really know when c9s will start pointing to rhel 9.1, we can only guestimate currently. Even if we know for sure, we have to ask centos stream folks to freeze their work until we sort out things on our side. And what if the package versions changed in rhel9 ga, because they found an issue in that build.
Why would the CentOS Stream folks need to freeze their work? Wouldn't we just stop syncing?
Would the packages match RHEL9 GA exactly? No. Would they be much much closer than if we used RHEL9 Beta? Yes
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision
fairly quickly.
I am okay with either plan A or plan B.
On Thu, Nov 18, 2021 at 3:04 PM Mohan Boddu mboddu@bhujji.com wrote:
On Thu, Nov 18, 2021 at 2:32 PM Troy Dawson tdawson@redhat.com wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
I like this plan as it is my brain child, it is what we have been communicating and planning, it doesn't really diverge from what EPEL has been. But... (see my opinion on Plan B)
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
Maybe we can run a mass rebuild to capture all the differences between rhel9 beta and rhel9 ga. That would solve one of the con's below.
I think a mass rebuild will be unnecessary with plan B or C. Out of the 2988 provided library sonames in the RHEL 9 Beta, I only found a single package with a newer soname in c9s, mptcpd. And mptcpd-devel is not shipped in the compose, so any package that builds against it now in epel9-next will fail anyways during the planned mass rebuild against RHEL 9 GA content.
mptcpd-0.7-3.el9 > mptcpd-0.8-1.el9 libmptcpd.so.1 > libmptcpd.so.3
At a library soname level, RHEL 9 Beta and c9s are almost identical at this point in time. That may change slightly as c9s evolves on the road to 9.0, but I suspect it will be a very small delta for soname differences.
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
I didn't see one question answered here, the maintainer has to request both epel9 and epel9-next branch or up until rhel9 ga if a maintainer requests epel9 branch they will also get epel9-next branch (like it was set up for epel8-playground). If we run a mass rebuild, then it wont be much different from that of Plan A, except there might be a few (or more, depending on delta) packages that will work on rhel9 ga.
As Troy mentioned, there will be no branch request magic. That was largely unpopular with maintainers when we did it for the playground repo. Going further on the branch request part, that helps illustrate my point that the guidance for plan A is confusing. Request epel9-next now, we'll mass branch epel9 for you, but after that point request epel9, unless you know you need an epel9-next branch to build against a library change that is in c9s but not rhel9 yet. I don't want to have to create flow charts for maintainers to understand the branch structure. Ideally I would like to match the epel8/epel8-next instructions from the start and have them stay the same.
So, I am not against this idea as well. One thing I would like to mention here is, even if we can setup this way since rhel 9 beta is out, we cannot do that same thing during rhel10 time as we might setup epel10-next way in advance before the rhel10 beta. We cannot keep this plan consistent going further.
I don't think we need to worry about making the exact same plan work for EPEL10 yet. Maybe we decide that our EPEL9 plan doesn't work for EPEL10 and we try something else. Maybe we plan from the start to launch EPEL10 after the RHEL10 Beta. I'd like to make the best choice for EPEL9 now, and then build off that when the time comes for EPEL10.
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
I can see how its advantageous, but I dont like this plan, since there are some uncertainties, we dont really know when c9s will start pointing to rhel 9.1, we can only guestimate currently. Even if we know for sure, we have to ask centos stream folks to freeze their work until we sort out things on our side. And what if the package versions changed in rhel9 ga, because they found an issue in that build.
We will have a really good idea of when c9s is preparing to switch to 9.1 content. And we don't have to ask CentOS Stream to do anything, we just need to stop syncing the mirror directory that corresponds to the EPEL9 koji target's external repo before 9.1 changes show up in c9s. It is extremely unlikely that a package version will change in a way that is significant to EPEL packages (library soname change) in that frozen time period.
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
I am okay with either plan A or plan B.
Troy
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson tdawson@redhat.com wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
Troy
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Thanks everyone for the feedback so far. I would still like to talk with the Fedora Infra folks in a bit more depth about the difficulty level of each plan, but at this point in time I feel like plan C is the best option because of the benefits.
- simple instructions to maintainers - simple instructions for users - no need for a mass rebuild, which is a big time saver - ability to have EPEL9 content ready on day 1 of the RHEL9 GA launch
I'm stating this as my opinion right now, not as the final decision. I'll defer that to an EPEL Steering Committee vote of course.
Dne 18. 11. 21 v 20:31 Troy Dawson napsal(a):
- epel9-next stays the way it is currently setup.
Ehm, what is the current setup?
And mainly, when I build something in EPEL next, something not compatible with EPEL. How it gets to EPEL when next RHEL 9.x gets released? I see nothing relevant at https://docs.fedoraproject.org/en-US/epel/epel-policy-updates/
The
https://docs.fedoraproject.org/en-US/epel/epel-about-next/
state that maintainer should do rebuild manually after the release of RHEL. That sound error-prone and leaves wide time gap when there may be broken deps.
Miroslav
On Fri, Nov 19, 2021 at 2:16 PM Miroslav Suchý msuchy@redhat.com wrote:
Dne 18. 11. 21 v 20:31 Troy Dawson napsal(a):
- epel9-next stays the way it is currently setup.
Ehm, what is the current setup?
Sorry about that. You are correct. I didn't say how epel9-next is currently setup. It is currently setup similar to epel8-next, except for a few key differences.
1 - epel8-next is built off the CentOS Stream 8 AppStream, BaseOS, and CRB repos. epel9-next is currently being built off the CentOS Stream 9 buildroot
2 - epel8-next repo is supposed to be layered on top of epel8, and only have those packages that would install on CentOS Stream 8, but not on RHEL8. This is normally very few packages. -- Since there is no epel9 at this time, all packages have to be in epel9-next
And mainly, when I build something in EPEL next, something not compatible with EPEL. How it gets to EPEL when next RHEL 9.x gets released? I see nothing relevant at https://docs.fedoraproject.org/en-US/epel/epel-policy-updates/
The
https://docs.fedoraproject.org/en-US/epel/epel-about-next/
state that maintainer should do rebuild manually after the release of RHEL. That sound error-prone and leaves wide time gap when there may be broken deps.
That is what this rollout proposal is about, figuring out the best way to do this rollout.
Do we keep everything in epel9-next until RHEL9 GA and then do a mass branch over and mass rebuild? (Plan A) As you said, this can be error prone and could leave a wide time gap.
Do we start epel9 now, and have it be like epel8 and epel8-next right now? (Plan B and C) If so, where do we get the RHEL9 packages? From RHEL 9 Beta ? (Plan B) From CentOS Stream 9 ? (Plan C)
Is there a Plan D that hasn't been brought up yet?
Troy
Dne 20. 11. 21 v 0:04 Troy Dawson napsal(a):
Do we keep everything in epel9-next until RHEL9 GA and then do a mass branch over and mass rebuild? (Plan A)
And again with 9.1 GA? And again with 9.2 GA? // I do not expect answer, just pointing that minor releases should be part of the solution.
Miroslav
On Fri, Nov 19, 2021 at 5:26 PM Miroslav Suchý msuchy@redhat.com wrote:
Dne 20. 11. 21 v 0:04 Troy Dawson napsal(a):
Do we keep everything in epel9-next until RHEL9 GA and then do a mass branch over and mass rebuild? (Plan A)
And again with 9.1 GA? And again with 9.2 GA? // I do not expect answer, just pointing that minor releases should be part of the solution.
Miroslav _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Historically most EPEL packages don't need to be rebuilt with every minor release, as RHEL libraries don't change often. When they do need to be rebuilt, it's been left up to the individual maintainers to take care of as their time allows. This has mostly worked OK for us.
Plan A would be a departure from the norm, where we do a mass rebuild at 9.0 for a "bootstrap" of epel9 content from epel9-next. At the last EPEL Steering Committee meeting we talked about doing mass rebuilds at every future minor release, but more or less agreed that this would be overkill and would result in a drastic increase in disk usage in the infrastructure. Additionally our existing mass rebuild tooling doesn't account for changes that exist in the epel9-next branches that need to be merged to the epel9 branches before building.
Plans B and C are more like the status quo, where packagers target epel9, and do individual package rebuilds as needed after a RHEL minor release.
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson tdawson@redhat.com wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
Troy
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Closing the loop here, at the 2021-11-24 EPEL Steering Committee meeting we voted and selected plan C.
https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html
We are in the process of finishing up the EPEL9 implementation and plan to launch EPEL9 and EPEL9 Next together with a formal announcement very soon. Until then you may notice parts of that implementation coming online (repositories, release packages, etc.) but we recommend waiting until the announcement for official instructions.
Am 02.12.21 um 19:49 schrieb Carl George:
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson tdawson@redhat.com wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
Troy
Closing the loop here, at the 2021-11-24 EPEL Steering Committee meeting we voted and selected plan C.
https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html
We are in the process of finishing up the EPEL9 implementation and plan to launch EPEL9 and EPEL9 Next together with a formal announcement very soon. Until then you may notice parts of that implementation coming online (repositories, release packages, etc.) but we recommend waiting until the announcement for official instructions.
That sounds nice! Just curious - what indicates the switch to 9.1 content? Any sample point(s) that indicates such "branch"?
-- Leon
On Thu, Dec 2, 2021 at 4:29 PM Leon Fauster via epel-devel epel-devel@lists.fedoraproject.org wrote:
Am 02.12.21 um 19:49 schrieb Carl George:
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson tdawson@redhat.com wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
Troy
Closing the loop here, at the 2021-11-24 EPEL Steering Committee meeting we voted and selected plan C.
https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html
We are in the process of finishing up the EPEL9 implementation and plan to launch EPEL9 and EPEL9 Next together with a formal announcement very soon. Until then you may notice parts of that implementation coming online (repositories, release packages, etc.) but we recommend waiting until the announcement for official instructions.
That sounds nice! Just curious - what indicates the switch to 9.1 content? Any sample point(s) that indicates such "branch"?
There are none. C9S is a continuously delivered distribution which RHEL is derived from. Equivalency to distinct RHEL minor releases at point-in-time intervals isn't something that Stream does.
In talking with Carl directly, he was using this as shorthand for instituting a freeze of the EPEL buildroot in preparation of solidifying it for a RHEL GA. RHEL's release cadence is publicly documented, so my understanding is that the EPEL team will do some of their own projections from the spring/fall RHEL release cadence (typically May and Nov) and work backwards to what they feel is a safe point in time to solidify.
josh
Am 03.12.21 um 02:12 schrieb Josh Boyer:
On Thu, Dec 2, 2021 at 4:29 PM Leon Fauster via epel-devel epel-devel@lists.fedoraproject.org wrote:
Am 02.12.21 um 19:49 schrieb Carl George:
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson tdawson@redhat.com wrote:
In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals.
- PLAN A
Plan A is basically what we've been working towards for the past couple of months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched.
** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now
** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists
- PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA
** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch
- PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later
** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB
** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch
Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly.
Troy
Closing the loop here, at the 2021-11-24 EPEL Steering Committee meeting we voted and selected plan C.
https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html
We are in the process of finishing up the EPEL9 implementation and plan to launch EPEL9 and EPEL9 Next together with a formal announcement very soon. Until then you may notice parts of that implementation coming online (repositories, release packages, etc.) but we recommend waiting until the announcement for official instructions.
That sounds nice! Just curious - what indicates the switch to 9.1 content? Any sample point(s) that indicates such "branch"?
There are none. C9S is a continuously delivered distribution which RHEL is derived from. Equivalency to distinct RHEL minor releases at point-in-time intervals isn't something that Stream does.
In talking with Carl directly, he was using this as shorthand for instituting a freeze of the EPEL buildroot in preparation of solidifying it for a RHEL GA. RHEL's release cadence is publicly documented, so my understanding is that the EPEL team will do some of their own projections from the spring/fall RHEL release cadence (typically May and Nov) and work backwards to what they feel is a safe point in time to solidify.
Thank you Josh for taking the time explaining the approach.
-- Leon
epel-devel@lists.fedoraproject.org
-
Carl George -
Josh Boyer -
Kevin Fenzi -
Leon Fauster -
Miroslav Suchý -
Mohan Boddu -
Neal Gompa -
Troy Dawson