On Tue, Jun 23, 2020 at 2:31 PM Josh Boyer <jwboyer(a)redhat.com> wrote:
On Tue, Jun 23, 2020 at 8:01 AM Miro Hrončok
> What makes RHEL so different that the failure is not relevant to it? Is it the
> stable nature of RHEL content? Is it the limited scope of RHEL content? Is it
> the less "wild" development process? Is it something different?
- Moves much much slower
- Has a base distribution that is extremely stable and does not
version bump often across the "platform" layer of libraries, etc
- Has a lifecycle that is equivalent to 20 Fedora releases (yes, twenty)
- Has a broader downstream ecosystem of ISVs and products that require
stability and continuity
A default module stream in Fedora, which is only around for 13 months,
provides little value when the next Fedora release likely is going to
have a different default or a newer version in 6mo anyway. Fedora
moves the entire distribution too fast for there to be a lot of usage
there. RHEL can pin on a default and have that be the default on a
long enough timeline that it actually works.
Are there other ways to accomplish the same in RHEL? Yes. Does that
mean failure in Fedora translates to failure everywhere? No.
This is actually a point I've raised multiple times over the past year or so:
I appreciate that Modularity and default streams actually solve some
problems that exist in RHEL, *because* it has a pretty long lifecycle.
However, this doesn't make much sense in fedora, *because* it has a
short lifespan (~13 months) and development cycle (6 months). In the
fedora case, the decision which version of a particular package to
include for which version of fedora is easily aligned with major
fedora releases, and this goes through either the Change process, or
packagers just apply the relevant Updates Policy.
In RHEL, waiting for the next major release won't work, so Modularity
can actually solve this problem by providing alternative versions for
those who need them.
Now, because ELN is "just" a subset of rawhide rebuilt in a more
RHEL-like environment, it is pretty closely aligned with the
development cycle of fedora, and so - in my opinion - iterating on
default streams and modules would be pretty painful (and pointless)
there, *because* rawhide moves so quickly that decisions on what (and
which versions) to modularize are obsolete after months or weeks, and
have to be revisited after 6 months at most.
For this reason, I'd argue that the decision about 1) which things to
ship as modules, 2) which versions should be shipped by default / as
default streams, and 3) which alternative versions to provide as
modules, should probably happen more closely to the RHEL-next side of
things than to the fedora side of things, and not in ELN. This has the
added benefit of allowing RHEL packagers and fedora packagers to work
*together* on the *default* version of packages, and then RHEL
packagers can provide alternative versions as modules on top of that.