On Fri, Oct 11, 2019 at 8:50 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > On Thu, Oct 10, 2019 at 10:41 AM Lukas Ruzicka <lruzicka@xxxxxxxxxx> wrote: >> >> 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. > > > > To be clear, I am reading every single reply to this thread very carefully. We *will* be taking all of this feedback into consideration, but please understand that we're also trying to balance things. As Neal noted upthread, we do have a responsibility to our downstream to make sure that we do not break the ability to manage default streams. This becomes much more difficult if we cannot have them in Fedora, because the testing of them is lost. Additionally, no one on the WG disagrees with you that the current state of things is undesirable. I take a moderate amount of offense to the repeated insinuations that the solutions we are building are "hacks". Yes, there's a proposal to work around the upgrade issue to F31 that is absolutely a one-off hack to buy time. But our plans for how upgrades should work long-term as well as how defaults need to behave in the distro are being considered very carefully. We are trying to avoid breakage and to make the process simpler, but we are also shoring up the bridge while crossing it. > Two years into this, I am currently not confident that modularity will be adapted to support community distributions well, especially fast-paced ones like Fedora. My fears about it encouraging Fedora to slow down has also seemingly borne fruit, too. Java is proof positive of this. Since the implosion of Fedora Java in the regular distribution and its move to modules, the traditional effort to move to newer Java versions has basically disappeared. Java 11 LTS was released last year, and to this day our default Java is still Java 8 (which is EOL!). Clearly, we're developing a new antipattern that we need to nip in the bud sooner rather than later. My disappointment in this became even greater when openSUSE beat us to switching to Java 11. Their packaging is derived from ours! They've demodularized Java for openSUSE and then did the work to move everything forward. Meanwhile, we've now failed at our "first" and "features" pillars because the incentive is now *gone*. > We are absolutely considering the option of disallowing default streams in Fedora, but we *really* don't want to rush into that. For one thing, we do have a number of packages that have moved to modules-only that would have to convert back. For some projects, this is probably just an annoyance, but for others this may be a major impediment. In particular, one of the advantages of Modularity is the ability to have buildroot-only packages that are different from the base operating system (and don't end up delivered as artifacts from the module). There are likely modules out there that rely on this behavior because their build requires a newer or older version of some package than the non-modular buildroot provides. This is not the sole problem to address if we go the "no defaults" route, just the first that came to mind. It's unclear to me right now if forcing everyone back to the old behavior is less effort than fixing the remaining Modularity issues. And since we need to fix them for RHEL as well anyway, it's worth considering carefully if the added work is worthwhile. > The buildroot-only packages thing should have been banned in Fedora. In my view, this feature is very much an anti-community feature, because it heavily discourages shared maintainership and permits even more orphanings than should be allowed. The more we do this, the less value the distribution itself actually provides. For example, it's pretty painful to package Rust software because you cannot rely on the existence of Rust components in the distribution. Everything *must* get built and integrated for each package. This not only defeats one of the major virtuous outcomes of Fedora participating in ecosystems (maintainers helping upstreams keep their software fresh and secure), but also makes it functionally impossible to distribute the workload of maintaining Rust packages in the same way we have for Python, C/C++, and Perl. > I'm wary of assuming that this thread represents the whole of Fedoran opinions, however. As we all know, it's generally the set of people who are upset that speak up the loudest. I'm not discounting your concerns (far from it!), but if we only base development decisions on "make sure no one is upset about it", we'd never accomplish anything new at all. This is why when I've been sending out these emails to discuss ideas, I've been trying to carefully describe both the use-cases and the technical limitations (both intrinsic to the design and those that are the result of imperfect implementation) each time. It's somewhat disheartening to hear responses that largely boil down to "If you can't get it perfectly right, stop trying!". At least this Fedora packager is getting super burned out with the number of problems caused in his day to day by the creation of module-only software in Fedora. I've never really had a problem with the idea of modules for alternative software, but I deeply despise the dependency on modularity for "default" software (per modularity parlance). I still don't have a good grasp of what to do anymore for packaging. I've edged away from packaging anything that involves modularity in Fedora proper because it's just too complex for me to grok. And as a third party packager, I really don't want to deal with modules for "default distro" setups. How am I supposed to make my software compatible with all of the potential module filters imposed on me by DNF? I don't know how to deal with depending on content existing in default modules either... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
