On Tue, Jun 23, 2020 at 11:21 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
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 <mhroncok(a)redhat.com> wrote:
> > What makes RHEL so different that the failure is not relevant to it? Is it
> > stable nature of RHEL content? Is it the limited scope of RHEL content? Is it
> > the less "wild" development process? Is it something different?
> Primarily, RHEL:
> - 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.
I'm not sure that follows. Rawhide is a continuous stream. Even
Fedora branches and stabilizes their releases in different branches.
Therefore you have an ability to iterate on something in ELN that is
longer than 6mo if it makes sense and with the proper planning.
For this reason, I'd argue that the decision about 1) which
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
I don't agree for 1 and 3. There is value in doing both of those in
ELN now and I don't see why we'd take the unfortunate and expensive
option of trying to do it all internally. Again, ELN represents a
space to do work in the open and part of that work is figuring out
which versions and modules make sense.
Item 2 may have challenges, but working on it in ELN will help
accelerate learning. If it fails, it fails fast and we all learn.
added benefit of allowing RHEL packagers and fedora packagers to
*together* on the *default* version of packages, and then RHEL
packagers can provide alternative versions as modules on top of that.
We could do all the non-default stuff somewhere else. CentOS Stream,
for example. I actually think that would be a net negative because it
splits the development ecosystem even further and reduces the feedback
loop with Fedora that we want for major release development. The more
experimentation and iteration we have to do *not* in Fedora, the less
relevance and influence Fedora has.