On Thursday, June 18, 2020 12:22:08 PM MST Josh Boyer wrote:
On Thu, Jun 18, 2020 at 1:59 PM John M. Harris Jr
> On Thursday, June 18, 2020 6:24:46 AM MST Josh Boyer wrote:
> > The base requirement is that the UX remain largely the same. As I
> > said, from a RHEL perspective, we need RHEL 8 and RHEL 9 to have
> > commonality so that our customers are not forced to learn something
> > entirely different to adopt RHEL 9. Improvements in the underlying
> > functionality are of course welcome and planned, but we are not going
> > to do something like replace modules with a different artifact type,
> > or add separate discrete repos per Application Stream, etc.
> Why is this a concern for RHEL9, where it wasn't for RHEL8? Moving to
> Modularity has certainly hurt RHEL7 migrations for exactly that reason,
> customers are forced to learn something entirely different to adopt RHEL8,
> and figure out undocumented issues with Modularity.
Actually, it was a concern for RHEL 8 in many ways. The introduction
of default module streams was a direct result of wanting to help
customers that are used to running 'yum install mariadb' still be able
to do that. The fact that it is packaged in a module is transparent
for that usecase. Customers wanting to use non-default Application
Streams will indeed need to learn some new commands and concepts, but
they still have some analogs to other technology we use in RHEL 7,
like SCLs, where newer content is accessible in different channels via
different tools. By having modules be implemented in yum itself,
those concepts become more central and common to the distribution
As with any new major release, there is always a need to introduce new
features or technology that causes some disruption. It is often the
only time we can do so in an Enterprise distribution. We try to
balance that with ease of use and adoption, which are always a top
concern. If you have issues with RHEL 8 and modularity, I would
encourage you to file a case in the Customer Portal. Getting that
feedback helps ensure we're addressing customer concerns.
> > > Basically this email just says "We decided for Modularity in RHEL 9
> > > and
> > > we would like to do it in Fedora Infrastructure first".
> > Mostly, yes. We were told there was ambiguity on whether modularity
> > would be used in RHEL 9 or not. Very clearly it will, so I wanted to
> > get ahead of that.
> That's unfortunate, and definitely isn't in line with what I've been
> in response to emails asking me to move my RHEL6 and RHEL7 systems to
> RHEL8, where I responded that we would wait for the next product. I can
> see how that may be out of line with your views, but I can't say it was
> really expected in this way. Thank you for clarifying. Has a stable
> Enterprise Linux product been considered, like RHEL5,6,7, perhaps moving
> Modularity to its own product for the few that have a use for it?
If you have problems with the RHEL 8 packages and functionality they
offer, please follow up through the support channels you have as a
RHEL customer. The distribution itself is quite stable, and in some
cases almost twice as performant as RHEL 7. I'd like to keep this
thread focused on Fedora, ELN, and modules if we can.
The issues I've seen so far affect both Fedora and RHEL, but have gotten a bit
better in Fedora. For example, a major concern that has been much worse in
Fedora than RHEL, for obvious reasons:
One month you can do a fresh install, install a package that, as it turns out,
is a module for some reason.
Then you install a fresh system the next month, install the same package.
Perform a dnf update on the previous system, and you'll find that you have a
different version of the package installed, because you're tracking a
different version of a default stream.
John M. Harris, Jr.