Hi Michael,
On Thu, May 28, 2020 at 5:30 PM Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Thu, 28 May 2020 18:08:48 +0930, Tim via users wrote:
> 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.
Please let's not create a thread of doom.
You can't seriously suggest blocking kernel maintainers from bugzilla just
because they don't have the manpower to take a look at every ticket and
perform meaningful, helpful triaging. Some key components are literally
flooded with bug reports. In order to deal with the number of tickets,
using scripts is an obvious thing to do. Yet it isn't done in a proper and
OS user-friendly way.
I agree, this is exactly the case (I'm the OP, and the person who
filed the BZ referenced earlier). There should be clear guidance how
a motivated user can follow through, do the relevant triaging, and
maybe even test an upstream kernel, In fact if you read the BZ,
you'll see that I tried vanilla RC kernels from Thorsten's repo and
reported back to the BZ.
What baffles me most, is the nature of the bug. It is the text book
case of a high priority bug, new (budget) hardware, which is becoming
common place very fast, where Fedora isn't bootable, add to that it is
a regression bug. How does a bug with these characteristics not come
within the peripheral vision of the maintainers, specially when the
reporter is eager to do all kinds of troubleshooting and testing!?
Clearly something is wrong with the automation, the question is. how
should that be fixed?
--
Suvayu
Open source is the future. It sets us free.