On Thu, Aug 20, 2020 at 2:18 PM Stephen Gallagher <sgall...@redhat.com> wrote:
> On Thu, Aug 6, 2020 at 10:46 AM Miro Hrončok <mhron...@redhat.com> wrote: > > > > On 05. 08. 20 21:36, Stephen Gallagher wrote: > ... snip > > > > I sincerely don't understand the RHEL's need for default modular > streams, but > > when I tried to query the motivation behind this, the answers haven't > made it > > any better: > > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YIUXL2AWY3GKITU4TBUSKL2IUHDUPB26/ > > > > Josh listed some of the key reasons behind default streams: that > enterprise customers don't like to learn new commands. So default > streams allowed us to package content with shorter-than-RHEL-lifetime > and still `yum install foo` would install something the customer could > use. > To expand on this a bit further, the product requirements for RHEL 8 Application Streams were to provide new software version options that were not disruptive to the end user and did not present a jarring experience during first impressions of RHEL 8. This included, but not limited to, examples such as: - As a SysAdmin, I need my kickstart file to work on the next release so that I can easily test and evaluate using my org's standard configuration. This is an important reality to improve adoption of RHEL 8. We had received much feedback from users in the past that "if my kickstart file does not work, I don't know when I'll find to troubleshoot why; I'll just set it aside for another day" [paraphrased]. So the request was that if they kickstart file listed "mariadb-server" the compatibility was there for the default to just work, with minimal edits to the config file. A user *could* specify a modular version with @mariadb:10.3/server if they *chose* to be that specific. But we needed a default mechanism to not break user experience. - As a SysAdmin, I need my automation scripts to work on the next release so that I can easily incorporate it into our environment. Roughly the same as kickstart. Our customers are more dependent on automation than ever before, whether that's shell scripts or ansible. And similar example scenarios. So in a nutshell, the idea was to not *force* the user to care about modularity unless they *wanted* to care. If they just wanted to treat it like the RHEL 7 experience relying on our recommended defaults, provide that experience. If they cared about different app versions, they had a native mechanism to enable that without figuring out a myriad maze of different repositories. That is the User Experience we (PM) requested. Default modules were the implementation solution that engineering recommended considering all other constraints. To be fair, we are biased towards the enterprise user/customer experience (note: that is a different persona than a package or distro maintainer). Without these users, we all have a major problem. And we know that RHEL 7 faced serious adoption resistance that we still receive negative feedback on even today. We wanted RHEL 8 adoption to be much smoother and easier for our users. Unfortunately, for the developer and maintainer personas it has been more painful. I hope we have expressed well enough that we are listening to all of our developers and working to resolve that. Hope that helps provide more clarity. Thank you, Terry Bowling Sr. Product Manager - RHEL Automation & Management Red Hat, Inc.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
