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. I seem to recall that RHEL does not officially support upgrades from version N to N+1, is that correct? 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. Pierre _______________________________________________ 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
