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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
