Hi, Igor, On Tue, Nov 12, 2019 at 4:20 PM Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Nov 12, 2019, 14:13 Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: >> >> 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. >> >> 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. > > > The question arises, what people are supposed to do when they modularized content because modularity is (was?) good tool to have "buildroot-only packages," "separate lifecycle from Fedora" and "no difference from normal packages." > > Second was rightfully prohibited by FESCo, first is making people not happy. Third one is not true. > > I basically had to go back, remove 28 out of 52 Fedora modules because tooling is not improving and policies are being more restrictive. Sorry, but I don't see this as a bad thing. I think you went too far and too fast with modularizing your packages creating basically separate stream for each minor release of an application, so reverting back to the old workflow is a good move at this point. > You say we need to improve tooling and iterate fast, fine. But why then https://pagure.io/releng/issue/7662 is still not implemented? I understand that it is opensource And everyone can contribute, but the fact is that people who work on Modularity tooling is entirely paid by RH and those people are "responsible" to bring it to Fedora and make it work. However, as written in the ticket "it is not a priority for that team". Also I don't think it is fair to bring topics like this. Referring to year old closed issue in the mail conversation is not constructive. Please at least reopen the ticket and get a feedback from the team on the current status and priority for it. > So is it really about making tooling (writing new, or making existing better) or about making those people to implement Fedora needs? "those people implementing Fedora needs" is a really bad way to put it. The fact that people are paid by Red Hat doesn't exclude them (us) from Fedora community. We are working on Fedora needs altogether, even when we disagree what those needs exactly are. Modularity team is a Fedora team in the first place, which is open for anyone to contribute. And yes it is about making tooling better, use cases cleaner and infrastructure more reliable. Again, no one forces you or any other packager to use modularity tooling right now. As Fedora developer you have a choice to join the effort, bring your input and use cases, try and test (and revert if it doesn't work) or you can stay away from it and keep using same tools as before. >> 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. >> >> -- >> Aleksandra Fedorova >> bookwar >> _______________________________________________ >> 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 > > _______________________________________________ > 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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
