Dne 12. 11. 19 v 14:04 Aleksandra Fedorova napsal(a): > Hi, > > On Tue, Nov 12, 2019 at 10:50 AM Dominik 'Rathann' Mierzejewski > <dominik@xxxxxxxxxxxxxx> wrote: >> Hi. >> I've been silent so far, while mostly agreeing with the "let's just drop >> Modularity" proposal. This post hit a nerve, so I felt compelled to reply. >> >> On Monday, 11 November 2019 at 19:24, Stephen Gallagher wrote: >>> On Mon, Nov 11, 2019 at 1:15 PM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: >> [...] >>>> It's really frustrating to be repeatedly told we're not arguing in good >>>> faith and then see things like this (from today's fesco meeting [1]): >>>> >>>> 15:48:07 <sgallagh> Can we please stop pretending like "start over >>>> from scratch" is a real option? >>>> >>>> Starting from scratch should be an option. Removing modularity entirely >>>> should be an option. Of course, so should be using modularity as it >>>> exists (or modifying it), but if we don't have those first two as >>>> options when there are proponents, this isn't a real technical >>>> discussion. >>> That quote is not fully in context, but that's entirely fair because I >>> didn't include enough context during the FESCo meeting. I apologize >>> for that. (Also, as you can tell from the rest of the log, I was >>> getting frustrated by that point). >>> >>> When I said it's not a real option, I did not include any of my >>> reasoning (thus Begging the Question as you rightly point out). My >>> reasoning is basically this: >>> >>> * Everyone on the Modularity Team is being paid by Red Hat to work on >>> Modularity. >>> * Red Hat Enterprise Linux 8 shipped with Modularity. >>> * The Modularity Team is responsible for maintaining that in RHEL 8 >>> regardless of what happens in Fedora. >> None of the above should matter for the purpose of selecting the best >> technical solution to the current issues, even if it means admitting >> that Modularity as currently implemented is causing too many issues that >> can't be fixed in reasonable time and abandoning it altogether. >> >>> * A full redesign in Fedora is not realistically possible with the >>> people and resources we have available to us while also maintaining >>> the current implementation for ten years. >> Then just drop it. SCLs are an example of a Red Hat-only solution. >> Modularity tried to do better and failed in Fedora, so let it remain Red >> Hat-only, too, while an even better solution is invented. Or, perhaps, >> as various folks have been saying, maybe Fedora just doesn't need SCLs, >> Modularity or any similar solutions. Let Red Hat cater to its corporate >> customers and experiment with Red Hat-specific solutions in CentOS and >> let Fedora not be constrained by what makes sense only in a LTS enterprise >> distribution. >> >>> * Therefore we are focused on trying to get the current implementation >>> into better shape (and/or finding a safe migration strategy to a new >>> solution) rather than start from an entirely green field. >> If you mean "we, the Modularity team" then I can understand, but still >> the option to just drop the whole thing from Fedora looks more appealing >> than just wasting more time and effort on piling up technical debt. >> Sound arguments were made against some of the stated goals of Modularity >> like private buildroot packages and the rest can be implemented using >> the existing tools. I fail to see what advantages Modularity has brought >> us so far, while the disadvantages are pretty clear. > I am going to disagree on several points here: > > 1) I don't think Modularity is about being LTS and "enterprisy". > Lifecycle differences are not the only feature Modularity provides. > > I see Modularity as a tool which bridges the gap between container > world and a packaged distribution. > > Without modularity we have a base system with its limitations and the > explosion of containerized solutions which currently go through their > teen-age phase, denying the good old known practices and reinventing > wheels in terms of packaging, sharing, deduplication of effort and > security audit. > > Modularity allows us to use packaging approaches in a more flexible > but still controlled and maintained way. It creates building blocks > for containerized environments. > I think it is the way to go for Flatpacks, cloud images and other > layered solutions to use runtimes built on top of packaged streams, > rather than custom configurations. > > And I think it is in scope of Fedora to drive this process to > normalize the currently chaotic container world. > > 2) I don't think Modularity is a failure in its current state. > > Yes, we do have a problem of default streams. There are several > reasons for that. > > One thing i find interesting is that: we were very cautious on tech > implementation side, delaying certain technical tools and solutions, > while we were not cautious enough on the process and policy. > And it feels like we should have done it the opposite way: iterate > (and sometimes fail) on the tooling faster, but have a much more > restrictive approach to the policy. Wasn't it the opposite way? If there was enough policies together with the tools, we could prevent some issues we are facing right now. Vít > > And now we are trying to evaluate Modularity without actually giving > it a chance to be implemented _for real_. > > Anyway, default streams is just one side of a story. It did get into > the critical path of Fedora and did create upgrade problems and > certain UX issues, but I think we can restrict and resolve it. > For that we need to focus on the issue, which is, from my point of > view: default streams and their differences from the ursine packages. > > One is caused by the lack of Ursa Prime, another is the upgrade > functionality, and I guess the third one is the non-api and filtered > packages in the module. > > P.S. I am not a member of Modularity team. > _______________________________________________ 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
