On Tue, Jun 23, 2020 at 8:01 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 22. 06. 20 21:36, Josh Boyer wrote:
>> I'd like to ask whether RHEL 9 has decided for default modular streams
>> 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?
- 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
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
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
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
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
> 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.