ELN Special Interest Group (SIG)
Mission
The goal of ELN (Enterprise Linux Next) is to achieve a continuously bootstrappable RHEL release. Using the classic approach, RHEL is forked from Fedora and developed privately for some extended time before it re-emerges fully formed as a Product. Instead, we want to take advantage of Fedora’s Rawhide and advances in CI/CD technologies to fork and begin hardening of a RHEL release at any arbitrary moment.
Resources
SIG Membership Responsibilities
Maintain documentation for ELN
Packaging work to optimize for RHEL
Maintain the ELN compose process
Evangelizing ELN as the place to develop Enterprise Linux
Meeting Schedule
A weekly meeting time will be reserved for the ELN SIG to meet. However, it will be canceled if there are no issues tagged with the meeting label. The meeting time will be selected by a public poll to determine the best available hour-long slot.
Decision Process
Issue Ticket Decisions
Any question that requires a decision by the ELN SIG must be filed as an issue in the tracker. Any SIG member can propose a solution to vote on. After one week has passed since the proposal was filed, if it has received +1 votes from at least three SIG members in the ticket and no -1 votes, the proposal is accepted. If after two weeks it has not received at least one +1 vote from a SIG member, the proposal is automatically rejected. If any -1 votes are recorded in the ticket or a SIG member explicitly adds the meeting label to the ticket, it will be discussed in the next meeting with quorum. Once this happens, a proposal may only be accepted or rejected in a meeting.
Meeting Decisions
Any proposal brought to a meeting will be discussed live at that meeting and then will pass or be rejected by a majority vote of those SIG members present (requiring a minimum of three SIG members for a quorum). A vote of +1 is a vote to accept the proposal. A vote of -1 is a vote to reject the proposal. A vote of 0 indicates that you are explicitly removing yourself from the voting quorum. For example, if there are four SIG members present in the meeting, a proposal can pass with a vote of either three votes in favor or two votes in favor with at least one SIG member voting 0.
FAQ
Who is sponsoring this effort?
Red Hat, Inc. (an IBM company) is providing resources in the form of infrastructure and personnel.
Is this a Fedora project or a Red Hat project using Fedora resources?
Yes.
What is the benefit of ELN?
The advent and refocus of CentOS Stream has provided a clearer story around RHEL development. Fedora remains the development hub for the next major RHEL release, while CentOS Stream fills that upstream role for stabilization and updates. Thus, some of us have started exploring ways to ensure that Fedora builds on its valuable position in the ecosystem.
We decided to focus on streamlining the process by which Fedora is forked and becomes Red Hat Enterprise Linux. Historically, we would pick a Fedora release, replicate its dist-git history internally and then proceed to make all the changes, tweaks, and hideous hacks needed to bootstrap RHEL. All of this would take place “behind the firewall,” and while we would usually pull in many of the changes from at least one subsequent Fedora release, for the most part this was effectively closed-source development from this point onwards until release.
With CentOS Stream on the horizon, plans are already in motion for more of the internal mechanisms being made public and visible. Therefore we decided to look at making the bootstrapping process a more continuous effort, rather than a complex ritual performed once every three years at midnight during a full moon. Thus, the seeds of ELN were born.
Do I need to be employed by Red Hat to be a member of the ELN SIG?
No, anyone with an interest in helping will be welcomed enthusiastically!
Do I need to be a provenpackager to be a member of the ELN SIG?
No, but it is certainly helpful. A lot of the ELN SIG work will be implementing tweaks and maintenance across a wide spectrum of packages. That said, there is certainly a place for non-packagers; we will need to produce documentation of our Standard Operating Procedures as well as recommendations to packagers, etc.
Why have ELN at all? Why not do this in CentOS Stream?
Great ideas have to start somewhere and Fedora is one of the largest idea incubators in the open source world. Why start development of an enterprise distribution after forking it from Fedora when we could do it concurrently? This would help to avoid the huge accrual of technical debt we then must pay off when the fork occurs.
That being said, some projects may want to wait until CentOS Stream is available before making their changes. There may be practical reasons for this (such as a personal preference not to maintain spec files with many conditionals). However, we feel that the majority of RHEL-destined packages would gain much from the longer and more visible development cycle.
I’m not particularly interested in RHEL; what other advantages does this bring to Fedora?
ELN will drive new features in the Fedora infrastructure, relevant to all contributors.
For example, a support for alternate buildroots and compiler flag experimentation, allowing us to test new features such as GCC 11 early, in a sandboxed environment. And tooling enhancements such as Jenkins automation, or the ability to define and monitor the content and installation sizes of various workloads using Content Resolver.
Even if you don't have a direct interest in ELN, but maybe share some of our infrastructure requirements or vision for your own uses, you're welcome to join us and help build it.
Is ELN SIG responsible for deciding what packages will be in RHEL?
This is a simple question with a complicated answer. Red Hat will provide ELN with sets of packages they absolutely want, and explicitly do not want, in RHEL. ELN SIG will be responsible for determining the surrounding packages needed as build and runtime dependencies. ELN will strive to minimize these dependencies as much as possible.
Is ELN SIG responsible for deciding on compiler/hardware features?
In general, we expect to work with the toolchain and kernel teams in Fedora and support whatever they recommend. For example, in ELN during its inception, we dropped support for ARMv7 because the set of compiler options we intended to use were not being tested or supported on that architecture.
How does ELN deviate from Fedora?
First and foremost, ELN will have a different set of RPM macro definitions from Fedora. The most obvious of these will be the %{rhel} and %{fedora} macros. This will be associated with conditionals in some of the other RPM macros, such as those defining default compiler flags. Packagers are allowed to use these macros in specfile conditionals of their own if they need to process things differently.
Some examples of cases where ELN may differ:
Disabling of experimental or uncommonly-used features in a package.
Shipping pre-built documentation to avoid build-time dependencies.
Integration with tools such as Subscription Manager
Where can I learn more?
Join us at the virtual DevConf.cz on Saturday, Feb. 20 for a public meetup!
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
