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. 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
