Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 11, 2020 at 12:32 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
> This exchange summarizes the situation nicely.
>
> Modularity can be considered an over-complicated hyped-through-the-roof
> bundling mechanism.
>
> For a long time Fedora has very strongly discouraged bundling in the sense of
> subsumming one package into another to have a custom build of a dependency.
>
> The disapproval of bundling is not because it doesn't work: it does, and in
> fact with some crappy libraries it's the least bad solution. The disapproval
> is motivated by the fact that bundling doesn't scale and that it subtracts from
> the ecosystem. Instead of us all cooperating and each bugfix helping all
> users of a given dependency, a maintainer of a bundled library is only helping
> themselves and their package.
>
> Bundling is not inherently bad: currently the policy even allows it as
> a workaround if using the system-wide package is not feasible. It is a
> pragmatic choice to allow it as a last resort. But the effect of bundling
> on other packages must be minimized any conflicts or confusion with the
> system version avoided.
>
> With Modularity, we threw this accumulated wisdom away.
> In two ways: by encouraging private^Wbuild-only dependencies and by
> letting bundled^Wmodularized rpms shadow normal rpms.
>
> For Maven packaging the appeal of Modularity is clearly the privatization of
> the dependency tree, which obviously undercuts the ecosystem of packages.
>
> The Java ecosystem collapsed so quickly because it was already weak
> — hundreds of packages on the shoulders of one person. But even in a stronger
> ecosystem, with enough packages modularized, the packaging ecosystem of
> mutual cooperation would collapse.
>
> For some other modules, the appeal is the overriding of package deps, which
> means that the modular rpms don't have to worry about getting it deps precisely
> declared, at the cost of breaking the deps declared in other packages.
>
> If there wasn't Modularity and instead Maven would bundle it's deps into
> one huge srpm, the effect on the ecosystem would be the same. As with
> bundling, Modularization gives short-term relief at a very high long-term
> cost. We should avoid modularization like we avoid bundling.

You summarized it really well, thanks Zbyszek. To me bundling is,
and always was, an important design feature of modularity.
There are other important aspects of it, but I dare to say that from my
PoV its form of bundling is the most important feature.

I wanted to expand on your story, present my version of the same story.

For a long time we (Java maintenance team at Red Hat) were maintaining
Fedora packages without any form of bundling because it was considered
harmful and was not allowed in any way, not without explicit exception.

Over time the number of contributors to Java packaging (number of active
Java SIG members) was decreasing, most of Java maintainers were gone,
or "unresponsive".  Making changes to our packages, like improving
packaging automation, required testing and possibly adjusting
thousands of others' packages, most of which were largely unmaintained.
Unresponsive maintainer processes would not work as it would require us
to take maintenance of orphaned packages, which we could not afford.

In the meantime our Java maintenance team was shrunk from 4 people
down to just one person, me.  I had to severely limit the time I spent
on Fedora due to other commitments - I had to spend more time on RHEL
work and other side projects, like Koschei, that I was responsible
for.  I could not afford to spend my free after-work time on Fedora
due to personal reasons (I got married, started building a house etc.)
Combined with the collapse of Java SIG, the situation was difficult.

Then a new, sophisticated way of bundling, called modularization, was
designed and came to my help. This way of bundling was no only
considered not harmful, but also approved and even made as a Fedora
objective. Since it solved the biggest issues I had with packaging, I
became a very eager early adopter and quickly built everything as
modules.

I was still maintaining non-modular packages, but I hoped that one day
non-modular packages would be completely replaced by modules.  When
modules were added to Fedora proper, I made them default streams and
waited for a solution like Ursa-Major that would allow me to retire
ursine packages, replacing them with modular packages.

RHEL enabled Ursa-Major. My javapackages-tools module was the first
ones to make use of it in RHEL and we succeeded to retire all ursine
packages in RHEL. When Fedora finally rejected Ursa-Major, I was very
frustrated as I perceived it as begin of collapse of modularity, the
great feature that promised to solve the problems I had with
packaging. I could not easily move back to ursine packages and I was
already committed to maintaining modules in RHEL, so I decided to live
with Fedora decision and orphan almost all of my ursine packages.

Since then I've been mostly working in MBI project, which has become a
new upstream for Fedora and RHEL modules. In MBI I made great progress
at improving the packages and reducing their number by more than half
- I didn't have to worry about breaking users or others' packages, and I
was not limited by constraints of Fedora infrastructure.

In the meantime modularity was mostly withdrawn from Fedora - default
streams and then module-only packages were disallowed, which to me
means total failure of modularity as a primary way of delivering
software to users.

Now I can't move on with modules as I don't have any chance against
anti-modularity trends.  I can't convert my modular packages to ursine
packages as this is not allowed by the policy, and would not be
appreciated by current owners of ursine packages.  I can't drop my
packages and move back to co-maintaining ursine packages as it would
mean losing 2 years of my work and the features I developed. The best
I can do is to wait and see what happens, while working on the
packages outside of Fedora, as part of the upstream MBI project.

>From a time perspective I do consider modularizing my packages as a
mistake.  But I don't see any sensible way of going back.

--
Mikolaj
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux