On Fri, Nov 20, 2020 at 11:16:03AM -0500, Matthew Miller wrote: > On Fri, Nov 20, 2020 at 12:03:27AM +0100, Emmanuel Seyman wrote: > > I suspect that these packages are maintained only to the point where they > > can build (and thus be used as buildreqs) but their maintainer also doesn't > > want them to be updated without making sure that the update will not break > > the package they are really interested in. > > That's probably also true. So communicating that reverse-dependency might be > another important aspect. CI gating should in theory help here. > > > What exactly do you want to do with this list of lightly-maintained packages? > > > > Is this something you want to present to end-users? > > Yes. Well, I'm not sure how we would do this. I mean a 'normally maintained' package still means the end-user should expect the maintainer to solve their bug when they are willing and able to do so. We don't promise any kind of turnaround on issues or deadlines on things. So how would a 'lightly maintained' package be different here? > > Is this a list we should show to people tempted to become packagers? > > Possibly? Maybe more appropriate for packagers interested in increasing > overall packaging quality. > > > Do we want to generate auto-replies to bugs filed in Bugzilla? > > Yes, I think so. Explaining the situation and asking for help. We may also > want to have a process for making sure that bugs which actually might > percolate up to the actual package of interest don't get discarded. The problem there is that there are lots of reasons for different maint levels, and it's hard to image a generic template handling that. Even if we bundle all the ones specifically in this exact case "I only maintain these packages because I care about 1 thing that uses them", it's hard to explain to users the expectation here. Imagine a bug against one of these packages that: * bumps to a new release/version. This might be fine, if the 1 package you care about still works fine, but might be something you reject if it doesn't. I suppose you could ask the user to test it and let you know? * Fixes some cosmetic bug that has nothing to do with how it's being used by the one package. If the maintainer had time they could apply/build this, but again would have to make sure it doesn't affect the thing they care about. * Is some complex thing that needs a bunch of investigation. I don't think the maintainer of the one thing will have time/energy to do that now, but not sure who would if we tell the user more? "The maintainer doesn't care about your bug because they only care about package X, you are on your own" is I suppose a bit better than silence in some ways. * Complains about an update that was needed for the one package. I would think this would be closed, sorry, nothing I can do either way? In the last FESCo meeting we got off on a bit of a tanget here talking about how we might look at improving all bug handling somehow. I think it might be constructive to look into ideas around that and they might help these 'lightly maintained' packages too? It's not a easy problem for sure. ;( There's currently 16,288 bugs against fedora components. About 84% of them are in "NEW" state. 570 bugs were opened in the last 7 days 555 bugs were closed in the last 7 days. (So, I guess right now we are treading water) The top 10 packages bug counts are not too surprising: kernel 1040 Package Review 730 gnome-shell 286 anaconda 267 selinux-policy 241 dnf 215 firefox 157 distribution 139 systemd 131 NetworkManager 95 Interestingly, 40% of our open bugs are against rawhide. Thats pretty amazing considering we move rawhide bugs to branched when we branch, so those 40% were all filed in the last months. > > > > Should SIGs keep a lookout for security fixes to apply? > > That would be awesome in general, I think. Always a good idea. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
