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.
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".
So is it really about making tooling (writing new, or making existing better) or about making those people to implement Fedora needs?
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
