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

List:       fedora-devel-list
Subject:    maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN
From:       Matthew Miller <mattdm () fedoraproject ! org>
Date:       2020-09-17 16:51:46
Message-ID: 20200917165146.GA32249 () mattdm ! org
[Download RAW message or body]

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.

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?


-- 
Matthew Miller
<mattdm@fedoraproject.org>
Fedora Project Leader
_______________________________________________
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]