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
