Re: RHEL 9 and modularity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <johnmh@xxxxxxxxxxxxx>
> wrote:
> >
> >
> > On Thursday, June 18, 2020 6:24:46 AM MST Josh Boyer wrote:
> 
> <snip>
> 
> 
> > > 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
> overall.
> 
> 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 told
> > 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.

_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux