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@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Am 02.12.21 um 19:49 schrieb Carl George:
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson <tdawson@xxxxxxxxxx> 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 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
