Thx for your reply and sorry for forgetting to CC you; that was the plan, but I forgot when I called git send-email :-/ Am 11.01.21 um 20:48 wrote Konstantin Ryabitsev: > On Sun, Jan 10, 2021 at 01:10:33PM +0100, Thorsten Leemhuis wrote: >> The front page doesn't make this aspect obvious and not even point to >> Documentation/admin-guide/reporting-bugs.rst to help those that want to >> properly report a bug. Only the FAQ mentions it, albeit only indirectly: >> 'The subsystem maintainers in kernel tracker are volunteers to help >> track bugs in an area they are interested in. Sometimes they are the >> same person as on kernel.org sometimes they are not. There are still >> some categories with no maintainers so more volunteers are needed.' > My general comment on this is that bug triage sucks and nobody really wants to > do it for any extended period of time. :) There were times in the past when > this or that person did step up and kept an eye on all incoming new bugs, > properly routing them to the proper product/component, but they quickly burned > out or found a less thankless occupation. Understandably. Yeah, I can relate to that, too. >> It looks like those volunteers were never found; the outdated list of >> components and products (see 'the bad' above) also shows that the >> volunteers seem to not really take care of things. > I want to encourage you and the rest of the developers to complain about this > to the TAB. It is entirely in their power to come to the Linux Foundation with > the suggestion that perhaps bug triage should be a paid position. It's not a > given that such a position would then be created and funded, but this for sure > won't happen if these complaints don't reach People In Charge Of Funds at the > LF. Hmmm, I'll have to think about that. I'm not sure yet if I'm currently willing to enter enter such a fight^w^w^w^w go down that route – I soon have other things on my plate and not much time to spare for this. Sure, bringing this to TAB is not that much work, but I expect that will lead to a longer process that will involve lots of arguments that will need to get exchanged by mail... And I don't care that much about bugzilla, that why I spend time wring the recently added text Documentation/admin-guide/reporting-issues.rst >> In the end that's the reasons why quite a few (a lot?) reports never get >> a reply from someone. During a randomly selected 2 week window at the >> end of November 2020(¹) there were 60 public bugs and a bit more than >> half of them by the end of the year never got a single comment by anyone >> except maybe the reporter. > Well, that said, a lot of stuff sent to the _proper_ mailing lists also never > receives a response Good point. > -- either because it didn't catch appropriate eyeballs or > because those eyeballs didn't have time to spend on the required > back-and-forth to identify the source of the problem. Or because the bug report was obviously so bad no one dared to touch it. But that reason and the two you mentioned are all covered in Documentation/admin-guide/reporting-issues.rst Sure, not everybody will read that far, but at least those that do will find help. And yes, the text could cover those situations for bugzilla.kernel.org as well, but that afaics would boil down to 'report to the place that is mentioned in the MAINTAINERS file (as you better would have right from the start)'. > I don't think we should > be using this metric as indication that bugzilla doesn't work. Well, FWIW, that's why I described it as 'doesn't work that well' and had a 'the good' section in my patch description, as it clearly is useful sometimes. That's also why I'm not on a quest 'kill bugzilla with fire'. ;-) Nevertheless I think discouraging users from filing bugs there is a good way to quickly improve the situation, as chances a good bug report will be acted upon afaics are currently much better when they get reported to the proper place: the one mentioned in the MAINTAINERS file. >> But there is one aspect that should be noted here: The situation can't >> be blamed on the kernel.org admins. They are doing a good job at keeping >> the bugzilla.kernel.org up and the bugzilla codebase up2date. But as >> admins it's not their job to maintain the list of products and >> components. > Aw, thanks. :) It's indeed hard enough just keeping all the spam off it. > Unfortunately, there are no perfect solutions for it, but usually all spam is > junked and hidden from public view within an hour or two of being posted. > Sadly, this usually happens after spammy notifications have already gone out. Ouch. Maybe that's one good reason to make bugzilla.kernel.org either work properly or kill it, to make sure the time your spent on things like this is actually worth it. >> Apart from this change there is one more change planned to improve the >> situation with bugzilla.kernel.org: discuss with the admins how to make >> it more obvious to users when to use the bug tracker, and when to avoid >> it; the text that does this will obviously link to >> Documentation/admin-guide/reporting-issues.rst, which is one of the >> reasons why it's designed to be understandable for newcomers. > I'm not sure there's any single solution that will solve the problem. If we > properly organize products/components, many people will just get lost in them > and create all bug reports in "other" (or "helpdesk", as is the case lately). Yeah, the kernel is complex and might benefit from a 1st level support that relays good reports to the appropriate developers or maintains. But such a solution would need time and money to set up. Until something is happening in that direction I'd say a patch like mine is a good idea and can easily get reverted later if the situation with bugzilla.kernel.org improves. > The sanest approach would be to have a simple web gateway to bug reporting: +1 > - which distribution are you using? > - if they choose a distribution, show them where to report bugs for that > distribution, because most bugs should start there, really Agreed. Fun fact: that why the step-by-step guide in Documentation/admin-guide/reporting-issues.rst starts with "Stop reading this document and report the problem to your vendor instead, unless you are running the latest mainline kernel already or are willing to install it. " ;-) > - on that page, also give a link: > "I'm a distribution maintainer and I want to report this bug upstream" > - if they click that link, let them fill out a freeform bug report that will > create a new bug entry on bugzilla.kernel.org in "Other/Other" > - creating a bug there will email the designated person in charge of initial > bug triage > - that designated person or persons will then assign proper product/component, > or simply forward the bug report to the proper maintainer if they are able > to ascertain that Well, do we really need bugzilla and a middleperson for triaging and forwarding when it we are taking about reports filed by distribution maintainers? They are unlikely to be newcomers to FLOSS bug reporting, so they IMHO should be able to read the MAINTAINERS file and follow Documentation/admin-guide/reporting-issues.rst > This is far from perfect and still hinges on finding a person willing to do > bug triage. However, it should hopefully improve the workflow without making > it too complicated. It might imrpove the workflow, but one question wasn't raised: why do we need two places to report bugs to at all? The MAINTAINERS file is there and the places specified there are clearly the ones maintainers prefer. Sure, bugzilla is easier to handle, especially for for inexperienced users. But is that worth it? Especially in its current state? Ciao, Thorsten
