Starting a new thread since the old one is hard to navigate at this point. Modularity is a distribution-level change and requires some mindset shift from packagers and users alike. I understand the concerns some people have, feeling it’s something new and half-baked that is being forced on them.
We’re an open source community and in order to drive innovation, we need to be able to try new approaches and technologies in the open, not develop them without any input and hands-on experience behind closed doors, later serving them on a silver plate. The feedback we’re getting is extremely valuable, but some of it is too narrowly focused on one specific problem area and not taking into account the other aspects, requirements, or goals that we’re pursuing. Our objective is still to deliver multiple versions, or variants, of our content across releases or even distributions (think EPEL or CentOS). And it’s a good one. The concept of default streams was introduced to make modularity invisible to anyone who has no interest in alternatives and wants the system to operate as it historically has. Whether a specific package is delivered via a module or not shouldn’t matter. (This does not mean it should be hidden, just that it should have no practical difference to the system.) This applies to both buildroots and runtime, leaving the choice of whether to modularize or not to the maintainer. Obviously, the implementation is falling short in this regard right now, but we have solutions in development or under design. This includes making the default streams available in the non-modular buildroot via Ursa Prime or tracking the module enablement intent in our software management stack, as Stephen suggested in the original post. While these issues are being resolved, we are considering temporarily disallowing default streams in Fedora. I don’t want to abandon the idea completely, as doing so reduces the motivation to actually build modules and reap the benefits they might provide. Yes, modularity still has some additional development ahead. We need to improve the software management stack experience; we need to revisit our release engineering SOPs; we need to stabilize and boost performance of our infrastructure; and last but not least, we need to improve the packager experience, providing more features to make the creation of modules easier, as well as guidance, best practices and policies that make it easy to collaborate. These changes are similar to those for other useful but disruptive technologies that Fedora has successfully introduced in the past. I do believe we all intend the best, even if we sometimes disagree. We currently don’t have any other proposal that would fulfill the vision of our Objective and the needs of our users. The input here helps us re-focus on the most acute pain points but the manpower and control we have is also rather limited. If you want to and can help with the implementation, I’d like to encourage you to do so. P _______________________________________________ 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
