[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:       David Cantrell <dcantrell () redhat ! com>
Date:       2020-09-18 15:29:20
Message-ID: 20200918152920.GL12508 () bnsf
[Download RAW message or body]

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?

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.

>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.
>
>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.

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

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