ELN SIG Launch

Friday, 12 February 2021

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

   -

   Documentation <https://docs.fedoraproject.org/en-US/eln/>
   -

   Issue Tracker <https://github.com/fedora-eln/eln/issues>

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
<https://github.com/fedora-eln/eln/labels/Meeting>;. The meeting time will
be selected by a public poll to determine the best available hour-long slot.
Decision ProcessIssue Ticket Decisions

Any question that requires a decision by the ELN SIG must be filed as an
issue <https://github.com/fedora-eln/eln/issues/new> 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.
FAQWho 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 <https://devconfcz2021.sched.com/event/gmYF/fedora-eln-meetup> at
the virtual DevConf.cz on Saturday, Feb. 20 for a public meetup!

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002