[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: Stephen John Smoogen <smooge () gmail ! com>
Date: 2020-09-17 17:30:26
Message-ID: CANnLRdhxYQXp_cJ1X1fkuWgkDfF9Crt=NT9V3e1JmXEF+070dw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, 17 Sep 2020 at 12:53, Matthew Miller <mattdm@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.
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, 17 Sep 2020 at 12:53, Matthew Miller <<a \
href="mailto:mattdm@fedoraproject.org">mattdm@fedoraproject.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 11, 2020 \
at 11:01:00AM -0700, Adam Williamson wrote:<br> > If one of the issues here can be \
stated as "we want buildroot-only<br> > packages because we don't want to \
maintain those packages to a high<br> > standard", it is demonstrably a \
viable choice within Fedora to just<br> > *not maintain those packages to a high \
standard*. Maybe we wish it<br> > wasn't the case, but this is a thing that \
happens all the time. We have<br> <br>
YES. In fact, *labeling* this is explicitly one of the things I wanted from<br>
modularity. I have a slide about this in one of my talks even, although I<br>
can't find it right now. The upshot is: packagers care about the software<br>
they want to run, and package up and maintain deps either because they want<br>
to do the right thing and be helpful -- or because they have to.<br>
<br>
I mean, some of y'all like to maintain and keep obscure dependency packages<br>
up to date just for their own sake, and that's *awesome* -- but we just<br>
can't hold everyone to that standard. At least, not if we want more than a<br>
few dozen packagers. So the *idea* was that modularity would let anyone<br>
express "I need these packages as dependencies, but I don't have the \
cycles<br> to maintain them" -- not because that's an awesome situation, but \
because<br> it's the reality and the status quo for a lot of things.<br>
<br>
Sooooo: RH Java packagers, what if you build these packages as non-modular<br>
(maybe using some scripting to make it happen at the same time as modular<br>
builds?) and add a readme explaining their maintenance state? I think that'd<br>
be preferable to where we are now, and it gets us to the next thing:<br>
<br>
* you could still help update and maintain these as time and inclination<br>
allows without feeling pressure, and... <br>
<br>
* rather than needing to do duplicative work all alone, the stewardship SIG<br>
could focus on serious security issues and high-priority bugs in this<br>
package set.<br>
<br>
That way, the application ecosystem would be available, the build deps would<br>
be there, and, actually, because of the collaboration, you wouldn't need to<br>
feel guilty about package maintenance state.<br>
<br>
<br>
What am I missing with this?<br>
<br><br></blockquote><div><br></div><div>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:</div><div>'its broke' </div><div>'yes I know its broke.. I \
just need the header files' </div><div>'well I need it to work' \
'well fix it yourself' </div><div>'no that is your job.. it says you OWN \
THE PACKAGE'. </div></div><div>'I just own it to build \
foobar'</div><div>'too bad.. i am taking this to \
lwn/slashdot/twitter/reddit'</div><div><br></div><div>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. </div><br \
clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div \
dir="ltr">Stephen J Smoogen.<br><br></div></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic