Lets follow the removing the maintainers if they don't respond to BZ'.s So we remove maintainers, we don't get a replacement maintainer and then after a few times of unmaintained packages, we remove the packages. Repeat until we have no packages except the most basic packages. Everyone seems to believe the maintainers are being paid to answer our questions by someone and/or required to respond to the BZ, they aren't. And there seems to be the believe that it is an honor to be a maintainer and that there are people waiting in line for the job, and they aren't. When you have paid support (read 10k's of paid distro copies) the maintainers always respond, and often the response is "engineering is looking at that" repeated until the enterprise packages goes EOL, or "we aren't going to fix that". Also remember the Distro maintainer is more or less just packaging it up and/or slightly adjusting for fedora and maybe some testing. They rarely own the original package source code, and rarely do they even know enough to do major code changes. I know I debugged and submitted code a fix to a package I like to use that had some code backported incorrectly and must have had only limited testing. Kernel bugs should be duplicated on the newest kernel.org kernel and then details posted to the linux kernel list, that will get it fixed upstream which in 30-60days or so will magically show up in fedora. Much the same thing is true with the packages, it is best to go to the actual package maintainer outside of the distro as they may have actually written the code. i know of at least one of "the engineering is looking at that" and/or "we aren't going to fix" that got fixed because someone I work with went to the upstream maintainer and fixed it at the source, and that got packaged up into the distro. If you fix it upstream you can also make the much simpler request to backport patch from upstream and/or uplift to current upstream the given package. On Thu, May 28, 2020 at 10:26 AM Tim via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Tim: > >> Perhaps there should be an automated culling of participants. If > >> you step up the plate to say you'll maintain a package, but don't, > >> *you* get dumped from bugzilla. > > Patrick O'Callaghan: > > I was about to suggest something similar. Not necessarily dumping > > them from BZ but removing the package's "maintained" status (or > > whatever the terminology is). Clearly if bug reports are not being > > addressed, the package is not being maintained in any meaningful > > sense. > > The trouble with dumping unmaintained packages is that you can remove > packages that actually work for some people (on distros that cull > unmaintained packages). Ignoring faulty ones, for the moment, there's > plenty of abandoned things that still work. Even broken ones may work > for some people. > > I do think it's fair to remove someone who isn't actually contributing. > There's no point in them being there if they don't do anything. > > -- > > uname -rsvp > Linux 3.10.0-1127.8.2.el7.x86_64 #1 SMP Tue May 12 16:57:42 UTC 2020 x86_64 > > Boilerplate: All unexpected mail to my mailbox is automatically deleted. > I will only get to see the messages that are posted to the mailing list. > > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx
