On Fri, Aug 23, 2019 at 5:49 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On 8/23/19 10:56 AM, Stephen Gallagher wrote: ... > > For default profiles, we have some options as well: > > > > Option 1: We disallow setting default profiles for EPEL streams. Pros: > > no risk of conflict with RHEL, should they now or in the future > > provide defaults for some streams of this module. Cons: `yum module > > install foo[:bar]` would not work (they would need to do `yum module > > install foo[:bar]/profilename`) and would likely irritate users. > > > > Option 2: We allow setting default profiles for EPEL streams. We take > > advantage of the defaults merging logic and ensure that if we need to > > supplement RHEL AppStream's defaults content, we must ship a > > modulemd-defaults document of the same `data.version`. This will allow > > them to be merged cleanly. Pros: Optimum user experience (they get the > > default profiles installed when they use the simplified install > > command). Cons: We need to constantly monitor each RHEL AppStream > > release and ensure that we aren't ever overriding (or being overridden > > by) RHEL. > > > > > > I think Option 2 is the better choice here (fewer angry users is a > > good thing), but I worry a bit about the maintenance burden of keeping > > track of the `data.version` values and ensuring they stay in sync. I > > think we can probably automate a good deal of this, though. > > > Yeah, I would like to do 2 also if we can manage to make it mostly > automated. > So, after discussing things at today's Modularity WG meeting, we've decided to make a breaking change to libmodulemd's merging logic to solve this much more cleanly. Full details are in https://github.com/fedora-modularity/libmodulemd/issues/368 With that change in place, Option 2 becomes the obvious correct choice, since we won't have to worry about the monitoring of the `data.version` values. _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
