On Wed, Oct 23, 2019 at 8:43 AM Petr Šabata <contyk@xxxxxxxxxx> wrote: > 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. Hi Petr, Thanks for your message. Yes, I think it's good to acknowledge that everyone here wants what's best for Fedora, even if we disagree on what that might be. I'd like to push back slightly on one point though: does the current modularity proposal really fulfil the vision of the Objective? Matthew posted the following three goals for the Modularity Objective from a recent council meeting: > 1. Users should have alternate streams of software available. > 2. Those alternate streams should be able to have different lifecycles. > 3. Packaging an individual stream for multiple outputs should be easier > than before. Now, please correct me if I'm wrong, but I don't think modularity-- at the moment-- actually accomplishes the third point. And in fact, I read the logs from the council meeting and some people made this point, and others have made it in the other threads: that the requirement to maintain module metadata for a module means that it'll almost inevitably be more work to maintain a one-package, one-stream module than it would be to just maintain one package. Now, this is just one point but... I think it speaks to what I feel is an expectation mismatch between "Modularity" as a thing the Council wants- a high-level proposal of a direction for the distribution-- and "Modularity" as an attempt to implement a real thing. I can only speak for myself, but I think some of the frustration that seeps into this conversation is a feeling or perception that modularity the *thing* can't be revisited because it's the realization of modularity the high-level *goal*. For example, reading the Council meeting logs, people talked about "trusting" (or "not trusting") the modularity contributors and their engineering decisions. With respect, I don't think it should be a matter of trust: we have a well-established process for making specific changes to Fedora. Changes get approved by FESCo, and if necessary, FESCo can decide to pull them or implement the fallback procedure. I don't see any reason modularity should bypass that process. Please understand: I'm not trying to demean or disrespect the modularity team or their work here. While I certainly understand the benefits modularity might bring us (there are packages I'd strongly consider modularizing), I want to be confident that decisions to roll it out are being taken because we think it's ready to be rolled out and that there are solid plans to mitigate problems we already know about it. Not because we need to implement the Objective at all costs. I said this in one of the other threads, but I would really like to see Modularity Guidelines drawn up before we allow further use of modules in Fedora. We should decide what is and isn't acceptable to modularize, what the rules are and aren't for creating and upgrading streams, and so on. And if we can't figure out a way to square the goals for modularity with the necessary guidelines to not cause major problems in the distribution... well, maybe that calls for significant rethinking? Sincerely, Ben Rosser _______________________________________________ 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
