On Wed, Oct 16, 2019 at 12:11 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2019-10-15 at 12:25 -0400, Neal Gompa wrote: > > > > > So: I'm on board with most of what you say here, but there's no need to > > > say it means Modularity is "a failure". It means right now it's not > > > entirely baked and we're realizing the concept needs extending and > > > perhaps reworking a bit, just like we realized with the *first* cut at > > > Modularity which we abandoned between a Beta release and a Final > > > release. This is causing us to have to deal with some icky problems, > > > but again, that's not *new*. We had to deal with some fairly icky > > > problems when systemd showed up. We had to deal with some fairly icky > > > problems when grub2 showed up. It's a process we've dealt with before. > > > We know how to do it. We just need to hold our noses and fix the icky > > > problems, and then sit down and think about the design issues that have > > > become apparent in Modularity v2 through our actually implementing it > > > and using it (which is what Fedora is for, remember!) and figure out > > > how to address them in Modularity v3. > > > > Are we going to do a Modularity v3? Because people seemed to be > > *really* reluctant to go down that path because it would break > > compatibility with RHEL. > > Well, those are just the terms I use to think about it, they have no > official validity. So in a sense it's a pointless semantic question. > Let's put it this way: I'd be surprised if we don't wind up having to > make significant changes/enhancements to the modularity rules and/or > implementation to be able to resolve the issues we're dealing with > right now (Stephen, in some of his replies, seems to agree) and to me > it'd be valid to call that 'modularity v3'. Whether anyone else would > call it that or not doesn't seem too important :) I agree with everything Adam just said. I'd avoid the term "Modularity v3" in general, because it sounds like a total redesign (which is what the v1->v2 switch ended up being). So far, all of the things I've been proposing have been done with an aim of not causing any additional breakage and to ensure that an upgrade path exists. That said, as we've rolled this out, new information has come up that is requiring us to re-evaluate some of the original design decisions (the most obvious being the "changing default streams" case). The two different proposals for how to handle that have been offered up because they provide an upgrade path to get out of the current situation without significant manual intervention. Also, I want to reiterate this point, because it is central: There are three core issues from which most of the complaints in this thread ultimately stem: 1) Modular default streams are not available to the non-modular buildroot, so packages that want to build against them are forced to either become modules or vanish from Fedora (or use complex build-time workarounds). 2) Once a stream has been enabled on the system, users are bound to it - even across upgrades between releases. Since the purpose of default streams is to eliminate the need for users to understand module interactions if they want to continue operating the way they did pre-Modularity, they need to be able to follow stream changes on upgrades to match the intended defaults for the new system. 3) The policy on default streams was not clearly defined and communicated. The Modularity WG recently voted to affirm that all artifacts installable from default streams of a module must obey all of the rules of packages in non-modular Fedora (primarily Stable Updates policy and the expectation that they are treated as supported API for all purposes). This is the "Java/Maven Problem", where the Java team created a maven module that included stripped-down dependencies in the default stream, thus owning those package names with unsupported content. We have plans in place for how to deal with each of these critical problems (without resorting to throwing it all away). 1) This will be solved by the new Koji/MBS feature that we've codenamed "Ursa Prime" (as a replacement for the original "Ursa Major" tool that was built for RHEL 8). Unlike its predecessor, it requires no additional daemon service running to handle things. We will create a buildroot compose for each release that is created from the set of packages available from all of the default streams and both Koji (in infra) and mock (on packager systems) will be able to consume this. Koji will behave the same as mock, where it will rely on libdnf's default module stream handling to populate the buildroot, so we won't have to worry about disparities between the local and infrastructure packager experiences. 2) There is an entire email thread [1] dedicated to how we are going to solve this. I won't repeat it here. 3) We need to get the policy I described above written onto -stone tablets- the Packaging Guidelines and then we need to go and make any stream that isn't compliant with it a non-default stream. [1] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/W4BCWO5ID2VIWZVUGWP7OMC7JCNOE5AZ/ _______________________________________________ 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
