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. Are there other ways to accomplish the same in RHEL? Yes. Does that mean failure in Fedora translates to failure everywhere? No. > I am not saying it isn't true, I am genuinely interested on the "whys" behind > your statement. Without them, I need to guess and it's obvious that once we > guess rationales of the words said by others, we cannot make proper informed > decisions or a reasonable discussion. You are smart enough to come up with your own reasons. The fact that you phrased them as questions rather than statements highlights your perspective on the discussion more than any actual merit of what I just provided above. > >> When discussing default modular streams in ELN, we have heard that ELN needs > >> default streams because RHEL 9 needs them. I would like to know if this > >> information is something that comes from RHEL leadership directly or whether it > >> is a personal option of the people who said such things. > > > > Why does it matter if "RHEL leadership" said it, or if a RHEL package > > maintainer said it? Politely, I find that an odd way to frame that > > discussion, devalues individual team autonomy, and ignores what the > > conversation points should be. Let me suggest a different way. > > Every package maintainer's (Fedora and RHEL alike) opinion matters. However, > when making distro-wide decisions, it makes total sense to evaluate the > following two statements with different merit, would you not agree? You mean like evaluating a technology across two different distributions with different merit? :) > a) "Grinch doesn't like modularity, he doesn't want default modular streams in > Fedora." > b) "After months of evaluation, the engineering leadership of Fedora has > decided that default modular streams are not allowed in Fedora." > > Similarly I'd like to know whether "we need default modular streams in ELN > because we need them in RHEL 9" is an opinion of a single person, single team, > whether it is an assumed opinion of the distro as a whole, or the documented > position of RHEL 9 leadership. Whatever the answer is, it doesn't make the > statement more or less valid, it merely helps us to better understand the scope. > > Since the "because RHEL 9 needs it" argument has so far been the end point of > the rationale, and since you've been so kind to share some RHEL 9 plans wrt > modularity on Fedora devel list, I've decided to ask about this particular topic > here as well. I see. I can offer only that we are driving from a position of continuity across RHEL releases unless there is reason enough to deviate. With RHEL major releases being every 3 years, the ability to change course rapidly(ish) exists but it would be extremely jarring to customers to do that. Particularly when many are still transitioning from RHEL 6 and RHEL 7. > We have spend 3+ Fedora releases debating default modular streams in Fedora and > once we were about to prohibit them, a request has come from ELN to have them. > Hence, I've assumed there were some RHEL conversations and decisions about > whether to have default modular streams in RHEL 9 even when they are not allowed > in Fedora and the request to have them in ELN is the direct result of such > conversations and/or decisions. To understand the reasoning, I've asked > clarifying questions. > > I am not trying to argue here, I am only asking for more insight. For me, the > request for default modular streams was surprising. Now I am trying to approach > the request with an open mind, but to do that, I would like to understand it better. Hopefully that provides more context. There may be more coming later as we can offer it, but I suspect it won't be on this list nor will it be in time for FESCo this week > > We know within RHEL we have teams that will likely continue using > > default streams. We also know that some teams will not. Further we > > know that somes teams will likely not use modules at all, just as > > teams in RHEL 8 did not use modules. The flexibility to choose the > > approach that makes the most sense for that team and their package set > > would be what I would hope we try to enable in Fedora and ELN. > > This is exactly the flexibility we've already had enabled in Fedora for 3+ > releases and after a very long and very painful discussion Fedora has decided to > prohibit it. Hence, I don't understand what are the reasons to have it in RHEL 9 > regardless, which is the reason I ask the questions. > > > It is > > fair to ask why a team would want to continue using default streams, > > and I can offer guesses but they would be only that. I would hope > > such teams could freely chime in here. The point is, within RHEL it > > is actually their choice to make, balancing the needs of their > > customers with the content they are packaging, etc. > > It remains unclear to me why Fedora would go out of its way to > > disallow usage of default streams in ELN. I understand they can > > present some issues if used incorrectly, or for something that is core > > to non-modular content, but the concept of a default stream being > > forbidden outright is strange. Default streams in ELN don't impact > > the wider Fedora distribution and removing them eliminates options and > > flexibility, forcing their usage to become a downstream-only concept > > which is exactly what we're trying to avoid with ELN to begin with. > > I haven't asked the questions to argue about this. I just wanted to get things > clarified, so we can have a discussion at FESCo based on some actual RHEL > information instead of guesses. > > Frankly, I don't know how RHEL decisions are made or who makes them. As a Fedora > package maintainer (and hence by extension an ELN package maintainer) I just > want to know what decisions were made wrt default streams in RHEL 9 and why, so > I can understand the request for default streams in ELN better. I would ask that you separate the possibility to create a default stream from the act of actually doing so. That's been the entire point of this subthread. If Fedora and/or ELN want to put guidelines in place that make it a broader discussion before something can be made a default stream in ELN, then go for it. However, forbidding them entirely just drives work elsewhere and that's counter to developing RHEL in an open manner. One of my favorite movie quotes is from Jurassic Park. There is a scene where Ian Malcom says "Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should." Normally I use this when pointing out some errant decisions. In this case, I'm actually asking to retain flexibility on whether ELN *could* have default streams and then further figuring out when they should based on merit. If anyone actually wants to influence future RHEL releases, writing up those kinds of guidelines has far more value than preventing a technology from being used. It allows people to use technology with responsible consideration, rather than making ELN a place full of giant distro-eating dinosaurs. 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
