On Mon, 2019-11-04 at 14:12 -0500, Matthew Miller wrote: > That said, it's hard to read "I see it as a solved problem and I > don't > understand why we are trying to solve it again" as ... helpful. > Consider the message that comments like this one and your last post send. I took the time to thoughtfully put together a set of ideas that can solve our problems in an easier and less controversial way by learning lessons from others who have traveled this path before us. You could have replied to my posts explaining why you think they won't achieve our goals. Instead, you have replied telling me that my efforts are not helpful, or that I need to have more details figured out than modularity does to participate in the conversation. You only quoted a single sentence from me - did you read the rest? Anybody can reply with a simple "what you wrote is not helpful", but it doesn't get us anywhere, and frankly it's lazy since you avoided countering my points, and a bit insulting too. The bigger thing to do would be to reply with substance describing why you disagree. You don't think other distributions have solved these problems in a way that we could easily apply to Fedora? Great, explain that position. Your posts communicate that you didn't seriously consider the proposal, and possibly that you aren't familiar with what my proposal is. The message they don't send is that you have listened, understood, and simply disagree. This type of communication leads towards division. If you have a serious objection to how these other solutions would not work for us, I think that would be a useful post for you to make. Show me that we have considered what other distributions have done, and why you think their solutions won't work for us. Even if I disagree, you will at least remove my complaint that due diligence wasn't done. I stand by what I wrote that you quoted here - I still don't see why we aren't studying the solutions to this problem that others have implemented and incorporating the best of them into our design. Given that my job is not to work on modularity, the most helpful thing I can do is to stand up and say "hey look, these projects solved our problems an easier way." I will say, as an aside, that I do think the "pro modularity" folks have otherwise fallen in the "I listened, understood, and simply disagree" camp, and I think that's great. We don't have to agree. As I wrote elsewhere, I completely understand why a thread like this is demoralizing for people who have worked on this. I'd feel the same way. I do think the conversation is still good to have, as long as it stays respectful. I wish there were a way to state our disagreements that wasn't demoralizing, but I'm afraid I don't know of a way. It's unhealthy if we can't discuss our disagreements. > Clearly it's not a solved problem in Fedora; we're not doing all this > work just to make people's lives harder or (as that same post seems > to imply) to reinvent the wheel. I do believe we are suffering from NIH here, and the reason I believe that is that I've asked if we have studied the solutions that exist to our problems, and I've not seen anyone say we have. If you ask that question enough times (I've asked this several times over the years), and can't otherwise find evidence that other solutions were studied, it is perfectly reasonable to say "hey, someone else did this, and they did it an easier way and weren't met with significant resistance to their implementations. Take a look." What this achieves is bringing attention to simpler solutions that would get us to our goal more quickly, and that would result in broader adoption among our users and contributors. Win-win. It is not reasonable to tell someone who is doing that that they aren't being helpful. That's not how an open project operates. Have we studied the other solutions to this problem? If so, let's document that we studied them, and why what they've done isn't useful for our goals. If not, surely you can see why that's a problem? I don't think anyone is trying to make people's lives harder. However, we *are* making people's lives harder, and that outcome matters. > A suggestion like "we should just use slots like Gentoo has" is not > really a > useful proposal. It's a 10,000-foot statement, and as we definitely > know, > the actual work is in the details. That's what I really meant, not > that I > expect Randy to do all of that actual work. The modularity project did not start off by having lots of details figured out, or we wouldn't have hit all the various issues we've hit. Indeed, it still does not have details figured out. It's unfair to hold anyone with alternate ideas to a higher standard than modularity has been held to, especially people who don't have a full time job of solving these problems. The solutions employed by other projects would not be difficult to adapt to Fedora just because we use RPM and they use other things. Many of the details of their solution still apply to us, and the ones that don't are still going to be simpler to deal with than what we have now. It absolutely is a useful proposal to suggest that we should study how other projects solved these problems. If you were going to start a web browser, wouldn't you start by familiarizing yourself with Firefox? Your objection here is like replying to "shouldn't we learn how Firefox did this" with "that's a 10,000 foot statement, how Firefox works is irrelevant to us". A browser designed with that kind of mentality will probably hit all the same XSS bugs that Firefox has solved over the years, because yes, the details matter, Firefox has solved many of those details, and they do apply to you as well. Gentoo, Nix, and Debian (and possibly others) have all solved the problems we face. They've solved their equivalents of the XSS bugs, and we would be wise to learn from them. > This is from the council meeting a few weeks ago: > > Our goals for modularity are: > > 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. > > The Gentoo slots mechanism says "This is useful for libraries which > may have > changed interfaces between versions — for example, the gtk+ package > can > install both versions 2.24 and 3.6 in parallel." This is fine. We > already > have a mechanism for installing simultaneous versions of packages in > parallel with nameversion munging. I happen to think that what we do > is > icky, and maybe bringing the Gentoo approach to RPM would be helpful. > > But it doesn't really address the above things at all. It's just > another > (possible) building block. Slots aren't actually how Gentoo does parallel availability. As I explained in another post, they are how they do what modularity calls "streams" and also how they do parallel installability. They do parallel availability by simply putting several versions of packages in the repo at the same time and letting me tell the package manager which ones I want. When I install the "python 3.6" slot, I am signing up for the "stream" of versions of Python in the 3.6 series. I will get updates for that stream as long as it exists in Gentoo, and when it ceases to exist, the Package manager will want me to remove it (and provides a helpful way to do this automatically for all my packages that are no longer supported). Gentoo certainly addresses both numbers one and two above. You can't just say it doesn't address it "at all" and wipe your hands. You have to defend a claim like that. How does it not address them? I'll show how it does address them. I've had "alternate streams of software available" to me for more than a decade in Gentoo, and I regularly make use of that feature. Their slots have different lifecycles. In fact, just this weekend I installed the latest and greatest Rust compiler on a Gentoo system that also uses the LTS kernel. I've been doing some Rust coding lately, so I'd like to be on the newer compiler, but my computer is 10 years old so I don't think I need to be on the latest kernel for my hardware. I can stay on my LTS kernel while signing up for the latest Rust compiler, and my computer will follow those "streams". Doing this in Gentoo was easy. Check it out, as of the time of this writing, I can pick from two different Rust versions that are considered "stable" in gentoo (the green ones), or from three that are in testing (the yellow ones): https://packages.gentoo.org/packages/dev-lang/rust Or take a look at Python, where I can sign up for the "3.6" slot which has (3.6.5, 3.6.8, and 3.6.9 available to me in it [yes, they even have parallel availability *within* slots!]): https://packages.gentoo.org/packages/dev-lang/python Check out how many versions of gcc I can pick from: https://packages.gentoo.org/packages/sys-devel/gcc As for #3, yeah, Gentoo doesn't do that (because Gentoo doesn't have versions for the distro itself [well, except for profiles, but that's another story], it's a rolling release). However, I think it's clear that modularity does not make packaging easier so it also doesn't address #3. See my post regarding the yaml file I had to make for rpick, or simply take into consideration the wide variety of complaints from packagers who have been affected by it. If it made packaging easier, I don't think we'd see so many people talking about how hard packaging has become lately. Also, you can put the same version of an RPM in all the versions of Fedora today pretty easily by just asking Koji to build the master branch for the Fedora versions you want. I've done this in a few cases, and it was simpler than creating large yaml files. Thus, #3 is already solved in Fedora today anyway, so if we implemented a solution like Gentoo (or Nix, or Debian) has done that would solve #'s 1 and 2, and we have it all. However, "making packaging easier" should be a separate initiative from "let users have more versions of programs available to them at a time". One of the problems with modularity is that people don't know what it is, and part of why they don't know what it is is that it keeps getting requirements added to it, to the point that it becomes confusing to talk about. This happens because each person that hears about it is exposed to more ideas than a person can take in at a time, so they walk away with a subset of those ideas. And each person walks away with their own subset. This is part of why modularity means different things to different people. One way to avoid that problem is to simplify the objective. It needs to be an elevator pitch, not a long document with many nuances. +1 to making packaging easier, but let's make that be its own goal (and really, a list of goals).
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
