On Tue, Jun 23, 2020 at 11:21 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > 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. 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 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 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 work > *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. 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
