> So despite providing zero feedback here, this was voted at the modularity > meeting: > > * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37) > * AGREED: We disagree with merging default streams into the main repo > as non-modular packages. Our approach is to implement a mechanism of > following default streams to give people the experience they want. > (+4 0 -0) (asamalik, 16:07:40) >
Well, based on this discussion, pushing content in modular defaults is not the experience that people want. I have been a bit ill for some time and before I could add my point to the discussion, everything has been more or less said. Just for illustration, this is what I wanted to say about it: 1. Modularity should stay away from my system until I call for it -> now it is not the case, because modularity sneaks into users' computer through modular defaults that overcome the non-modular packages. Gimp is the first such "horse" that jumps into almost everybody's desktop and they are modular without even knowing it. 2. Modularity should provide alternative content, if I need it and when I need it. Modules should be installable only through "dnf module" command and not through the regular dnf command, so that I explicitely need to allow modularity on my system. 3. The naming conventions of the streams should be *obligatory* for every module packager. So, if we decide that we want a "latest" stream, then all modules should have a "latest" stream for rolling updates. Currently, they all have various names of streams, from which I cannot tell anything. If there should be a "slow" path, then again, all modules should have a "slow" path. 4. Non-modular Fedora must be a valid use case and remain an option. 5. If I decide to go modular, there must be a way to go non-modular again, without breaking the system. Or, if modular is the only option, so if I go into specific streams, there must be a way to go to defaults without breaking the system. With non-modular defaults, this seems easy. With modules? I am not sure. 6. We need to expect that once there are hundreds of modules, people will install all possible combinations and they all will need to work. I am not sure, we will be able to test something like that. Seeing the reaction of the Modularity WG ... I do not understand how it is possible that such important decisions are taken by 4 people without any Fedora wide discussions like this. And yet, it seems a little bit that even opinions on this list will not fall on fertile grounds. I wish the communication improved in the first place. Community means togetherness. > should aim for solution 1. if solution 2. is not negotiable by the > modularity WG. > +1 -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzi...@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
_______________________________________________ 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
