[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding
From:       Fabio Valentini <decathorpe () gmail ! com>
Date:       2020-09-19 14:55:34
Message-ID: CAB-QmhQoq3zkUwCAFTgS7Q7yw5f9O+vyOo8HpWCNxcw6BoSfog () mail ! gmail ! com
[Download RAW message or body]

On Fri, Sep 18, 2020 at 5:30 PM David Cantrell <dcantrell@redhat.com> wrote:
>
> On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:
> >On Fri, Sep 11, 2020 at 11:01:00AM -0700, Adam Williamson wrote:
> >> If one of the issues here can be stated as "we want buildroot-only
> >> packages because we don't want to maintain those packages to a high
> >> standard", it is demonstrably a viable choice within Fedora to just
> >> *not maintain those packages to a high standard*. Maybe we wish it
> >> wasn't the case, but this is a thing that happens all the time. We have
> >
> >YES. In fact, *labeling* this is explicitly one of the things I wanted from
> >modularity. I have a slide about this in one of my talks even, although I
> >can't find it right now. The upshot is: packagers care about the software
> >they want to run, and package up and maintain deps either because they want
> >to do the right thing and be helpful -- or because they have to.
> >
> >I mean, some of y'all like to maintain and keep obscure dependency packages
> >up to date just for their own sake, and that's *awesome* -- but we just
> >can't hold everyone to that standard. At least, not if we want more than a
> >few dozen packagers. So the *idea* was that modularity would let anyone
> >express "I need these packages as dependencies, but I don't have the cycles
> >to maintain them" -- not because that's an awesome situation, but because
> >it's the reality and the status quo for a lot of things.
>
> Burying build-only dependencies in a module adds more work in the long
> run.  If something-doc-tool is a build dep for a module and is now
> part of that module, it's visibility is decreased to other package
> maintainers that may want to use it.  Being able to find it now puts
> the burden of having detailed knowledge of every module in the
> distribution as well as the distribution itself on all package
> maintainers.  And then if they find it, how can they use it since it's
> part of a module as a build only dep.  Can it become part of another
> module?  Say it can, now work has to be coordinated among the package
> maintainers using something-doc-tool as a build dep so they don't
> duplicate work.  The net gain here is that we have avoiding exposing
> something-doc-tool as a package that users can install?  Why?
>
> As stated elsewhere on the thread, to achieve what you're describing
> is much easier in other ways.  I don't know why we haven't explored
> creating an additional repo of shared build deps or even just "rawer"
> packages that maybe don't get the maintenance attention that other
> packages do.  We already know that goes on, but the packages are just
> part of the main repo.  So instead of classifying them collectively
> and keeping them open for shared and collaborative maintenance, we
> want to make them hidden build deps in modules?

(snip)

> New community members looking to become package maintainers... if we
> had a grouping of packages in need of care that were only build deps
> for other packages, the barrier to entry is less daunting if you know
> that you won't have a million users.
>
> TL;DR modularity decreases component visibility and works against open
> collaboration.

I completely agree. The only way to move forward is to make
maintenance of shared parts of the stack a collaborative effort.

> >Sooooo: RH Java packagers, what if you build these packages as non-modular
> >(maybe using some scripting to make it happen at the same time as modular
> >builds?) and add a readme explaining their maintenance state? I think that'd
> >be preferable to where we are now, and it gets us to the next thing:
> >
> >* you could still help update and maintain these as time and inclination
> >  allows without feeling pressure, and...
> >
> >* rather than needing to do duplicative work all alone, the stewardship SIG
> >  could focus on serious security issues and high-priority bugs in this
> >  package set.

Just to clarify, the Stewardship SIG now maintains zero packages.
The handful of NodeJS packages we had were either dropped or adopted
by somebody else ages ago.
All Java packages were moved into the "rebirthed" Java SIG.

> >That way, the application ecosystem would be available, the build deps would
> >be there, and, actually, because of the collaboration, you wouldn't need to
> >feel guilty about package maintenance state.
> >
> >
> >What am I missing with this?
>
> I think this is on the right path.  Shared ownership and collaboration
> is a good way forward for these types of packages.

Yes. That's kinda the reason I "restarted" the effort for a Java SIG?

The initial progress (then still under the Stewardship SIG umbrella)
was slow - because almost everything was old and broken - but now, the
Java stack is in *much better shape*. Arguably, it is in better shape
than it had been for years, being ~75% up-to-date with upstreams now,
with *zero* FTBFS issues for f32+, and *zero* open CVEs in the core
stack.

We already did the hard work of keeping everything from exploding. Now
it's mostly back to normal, boring package maintenance. This is also
conducive for getting new people involved with the Java SIG. The
barrier of entry is much lower now, since not everything is broken
left and right, but actually surprisingly pleasant to work with.
Making incremental changes and updates is much easier when the stack
is in good shape ...

I've also been seeing an increasing number of contributions (and
contributors) over the past months. It turns out, some of our packages
are depended on by basically the entire distro (including libreoffice,
FreeIPA, libvirt, qemu, etc.) so packagers are actually interested in
keeping things working, now that the stack is not threatening to
implode any day.

Fabio

> If I am using a package as a build dep and find it's outdated or
> broken in some way, I can fix it and send a PR in Pagure to update it.
> The maintainer can review and merge that or at least start a
> discussion with me on the why and how of the change.  I haven't had to
> take complete ownership of that package, but just spent the time to
> fix the problem I saw.  For packages in a less than bleeding edge
> ultra stable state, my main concern is that they are functional rather
> than latest version.  I suspect many of us also prefer that for build
> deps in most cases.
>
> Maybe in addition to a per-package README, a broader communication of
> this process to the community as well as providing a link to open bug
> queries for packages would be useful for work similar to the "kernel
> janitors" type work for the kernel.  Lots of stuff has to be done on
> an ongoing basis and everyone can chip in from time to time.  We could
> consider a standard doc name like "MAINT" or something in the package
> that describes the specifics regarding maintenance in Fedora.
>
> Thanks,
>
> --
> David Cantrell <dcantrell@redhat.com>
> Red Hat, Inc. | Boston, MA | EST5EDT
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
> 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@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]