On Thu, Nov 18, 2021 at 2:14 PM Kevin Fenzi <kevin@xxxxxxxxx> 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@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 -- Carl George _______________________________________________ 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
