On Tue, Jun 23, 2020 at 2:31 PM Josh Boyer <jwboyer@xxxxxxxxxx> wrote: > On Tue, Jun 23, 2020 at 8:01 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > 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. > > 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. Fabio _______________________________________________ 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
