Re: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN and RHEL)]
On Thu, 17 Sep 2020 at 12:53, Matthew Miller <mattdm(a)fedoraproject.org>
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.
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?
Those packages get bugs and bugzilla is a monkey on the back of every
packager.. having a ton of packages which you know you aren't going to fix
but are still going to get bugs on with the conversation going like:
'its broke'
'yes I know its broke.. I just need the header files'
'well I need it to work' 'well fix it yourself'
'no that is your job.. it says you OWN THE PACKAGE'.
'I just own it to build foobar'
'too bad.. i am taking this to lwn/slashdot/twitter/reddit'
I think that if we are going to have 'extra' packages which are needed for
'core' packages, we should be explicit and own the fact that this 'package
everything for everyone' only worked when working on Operating Systems was
'hot' and has been replaced with cloud, containers, and whatever other
sugar coated candy cereal people have to have with a toy inside these days.
--
Stephen J Smoogen.
Attachments:
- attachment.html (text/html — 3.8 KB)