Re: RHEL 9 and modularity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 23, 2020 at 10:14 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
>
> On Tue, Jun 23, 2020 at 08:30:37AM -0400, Josh Boyer wrote:
> > On Tue, Jun 23, 2020 at 8:01 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
> > >
> > > On 22. 06. 20 21:36, Josh Boyer wrote:
> > > >> I'd like to ask whether RHEL 9 has decided for default modular streams despite
> > > >> their failure in Fedora, whether this decision is final and what was the
> > > >> reasoning behind it.
> > > >
> > > > That's an interesting question.  I think for the purposes of this
> > > > discussion, we should acknowledge that usage of default module streams
> > > > in Fedora and usage in RHEL aren't equivalent.  Therefore, failure of
> > > > adoption in Fedora doesn't necessarily equate to failure in RHEL.
> > > > With that context, I'll continue.
> > >
> > > Before we continue with that context, could you please elaborate on this?
> >
> > If I must.
> >
> > > Obviously  we can say "usage of default module streams in Fedora and RHEL is
> > > different" and to some extent this will always be true. However I would  like to
> > > know why they are *significantly* different to justify saying  the failure in
> > > Fedora does not necessarily mean RHEL would experience  the same failure.
> >
> > For all the same reasons SCLs and containers are widely used and
> > adopted in RHEL, but not Fedora.  (And before people say "Fedora has
> > containers", I know that.  They're fine.  That doesn't mean you see a
> > massive adoption of Fedora base images on a wide scale.)
> >
> > > 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?
> >
> > 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.
>
> I have most definitely been less involved than Miro on the modularity work, so I
> may be wrong (and will happily stand corrected if so) about the following.
> If I understood correctly one of the major issue with default streams were
> basically upgrades: how do we go from Fn to Fn+1?
>
> RHEL has the advantages that your points #1 and #3 above high-light, however, I
> expect that the upgrade question of default stream will still show up between
> say RHEL8 and RHEL9.

It will, but it is different than how it presents itself in Fedora.

> I seem to recall that RHEL does not officially support upgrades from version N
> to N+1, is that correct?

No.  There are some constraints around what is supported but we have
tooling that aids upgrades from RHEL 7 to RHEL 8, for example.  It
analyzes and assists customers in doing that operation.  You can find
more information here:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/upgrading_from_rhel_7_to_rhel_8/planning-an-upgrade_upgrading-from-rhel-7-to-rhel-8

> If so, there is right here a key difference between Fedora and RHEL: the life
> cycle of a default stream is fixed to the life cycle of the underlying OS
> without supported possibilities to move from version N to N+1.
> If we were to do that in Fedora (not support N -> N+1), it is likely that the
> default stream question would be much less problematic and vice-versa if Red Hat
> start supporting upgrades from RHEL8 to RHEL9, the default stream question would
> likely become much more challenging there.

Indeed, RHEL 8 -> RHEL 9 will have a challenge in some ways.  However,
a major RHEL release is also very different from a Fedora release, at
least in this regard.  Major RHEL releases are boundary points where
defaults can and will change, which is possible because our lifecycle
is so long.  Within a single RHEL major version though, the defaults
don't change from one minor release to another (e.g. 8.2 -> 8.3).

Fedora actually tries to mix both models within its release framework
today, and struggles with it because the lifecycle is so short from
one release to another.  It is somewhat unique to Fedora, and it's why
it takes 3-4 releases to make a default change.

josh
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux