Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
On Wed, Jan 13, 2021 at 01:17:10PM +0200, Jani Nikula wrote: > >> Well, that said, a lot of stuff sent to the _proper_ mailing lists also > >> never > >> receives a response > > > > Good point. > > There's a school of thought that this is actually a feature. If there's > no attention, the reports on the list will just fade away and be > forgotten. Whereas in bugzilla, someone needs to actively resolve even > the ignored and forgotten bugs. (Or it needs to be automated.) FWIW, it's easy for me to script this, if there is consensus that a bug that hasn't seen any activity for longer than N months should be auto-closed with some apologetic comment like: This bug has aged out and will be auto-closed. Sorry that it didn't work out. If this issue is still present in recent kernel releases, you may need to reach out directly to subsystem maintainers in order to get their attention regarding this problem. Please do not re-open this bug without the above step, as it will simply get auto-closed again in the future. > Attending to a bug database of thousands of open bugs takes a huge > amount of effort, and if the bugs aren't being fixed, a lot of that > effort is just wasted. If a bug doesn't get fixed now (or soon-ish), > what are the chances it'll get fixed months or years down the line? Well, it's *possible* that someone comes across that bug during their research and adds enough additional information to get it fixed. However, this is extremely unlikely and it's better to just open a new bug anyway. > Just musing, has anyone else seen a shift in bug reports from "I'm part > of the community, and I want to help improve this stuff" towards "I'm a > customer and I demand support"? I don't think the kernel community can > really cater to the latter very well, and would be better directed at > distro bug trackers. I haven't seen any specific change like that. One good thing about bugzilla is that people who do file bugs have already overcome significant barriers to sign up and navigate the quaint, decades-old bugzilla interface -- so their bug reports tend to be generally well-written. -K
Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
On Tue, 12 Jan 2021, Thorsten Leemhuis wrote: > 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. There's a school of thought that this is actually a feature. If there's no attention, the reports on the list will just fade away and be forgotten. Whereas in bugzilla, someone needs to actively resolve even the ignored and forgotten bugs. (Or it needs to be automated.) Attending to a bug database of thousands of open bugs takes a huge amount of effort, and if the bugs aren't being fixed, a lot of that effort is just wasted. If a bug doesn't get fixed now (or soon-ish), what are the chances it'll get fixed months or years down the line? --- Just musing, has anyone else seen a shift in bug reports from "I'm part of the community, and I want to help improve this stuff" towards "I'm a customer and I demand support"? I don't think the kernel community can really cater to the latter very well, and would be better directed at distro bug trackers. BR, Jani. > >> -- 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 prop
Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
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 tra
Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
Am 12.01.21 um 00:42 schrieb Randy Dunlap: > On 1/11/21 10:55 AM, Thorsten Leemhuis wrote: >> Am 11.01.21 um 19:14 schrieb Randy Dunlap: >>> On 1/10/21 4:10 AM, Thorsten Leemhuis wrote: > >>> Andrew Morton takes MM bugs and Cc:s them to linux-mm mailing list >>> and then asks for discussion to continue on the mailing list. >> Then what use it bugzilla here? Wouldn't it be better for people to go >> straight to the list? > Might as well, yes. Yeah, and that's among the reasons why I wrote the new document on reporting bugs/issues (which explains how to report issues by mail) and additionally work (at least for now) towards discouraging people from using bugzilla.kernel.org. >> Just trying to understand things better here, as there are other things >> that look strange to me and were mentioned in the patch description. For >> example: Why are there only 200 products and components on >> bugzilla.kernel.org (some of them for historic things like the >> ac-kernels) while the MAINTAINERS file has more than 2200 entries? > I wouldn't want a separate entry for each SPI/GPIO/regulator/USB etc. > device. That's just IMO... I can relate to that view, but OTOH that would means a middleperson is needed to get in contact with the maintainer. Which is fine concept, as that person could be a kind of 1st level support that shields higher level people like developers and maintainers from bad bug reports. But I guess that would be a boring job which I nobody will do over longer periods of time just for fun. Sure, the LF or someone else could hire someone (see the mail from Konstantin in this thread; will reply to that later); but I wonder if we have more pressing issues where the money would better be spend better. And even if not: getting that money and hiring someone would take some time... >>> could/should probably see if we can add more project-specific >>> mailing lists to the automatic reporting >> Guess that would mean taking to a lot of maintainers/mailing list admins >> if they are okay with that. Who would do that? > whoever is motivated to do so. Not me. ;-) That bugzilla.kernel.org is not working to well is known for years now, without anyone stepping up to improve the situation for real. Maybe my work/this discussion gets something rolling. But I guess until I see that happen I continue working towards discouraging people from using bugzilla.kernel.org, as otherwise things will just stay as they are, which IMHO is a bad idea with the state of things. Ciao, Thorsten
Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
On 1/11/21 10:55 AM, Thorsten Leemhuis wrote:
> Am 11.01.21 um 19:14 schrieb Randy Dunlap:
>> On 1/10/21 4:10 AM, Thorsten Leemhuis wrote:
>>> * About 66 of those ~200 components will assign bugs to email addresses
>>> that look valid, but 125 of them end with @kernel-bugs.osdl.org or
>>> @kernel-bugs.kernel.org. Those domains do not exist anymore, mails
>>> sent there bounce ('Unrouteable address'). It's possible that the
>>> server might be rewriting those domain names and nevertheless
>>> delivers new reports and comments by mails to some human; but it
>>> seems more like they never get mailed to anyone and thus just linger
>>> in the database; no wonder quite a few of bugs filed against such
>>> components never get a single reply (see below).
>>
>> Those @kernel-bugs email addresses should not be a problem:
>>
>> https://korg.docs.kernel.org/bugzilla.html#real-assignees-vs-virtual-assignees
>
> Ahh, interesting, many many thx. Stupid me also forgot to put Konstantin
> on the CC list (I had planned to do that, but forgot when I actually
> sent the patch :-/ ), which likely would have pointed be there as well.
Yes, since I got that from him. :)
>> AFAIK, USB bugs go to linux-...@vger.kernel.org,
>
> Those seem to use the approach the link above describes.
>
>> SCSI bugs go to linux-s...@vger.kernel.org.
>
> That's one of the email address that are in the database for real, which
> were mentioned in my patch description as 'looking valid':
> https://bugzilla.kernel.org/describecomponents.cgi?product=IO%2FStorage
>
>> netdev didn't want bugs sent there automatically IIRC, so a
>> human takes care of doing that if warranted.
>
> Ahh, good to know, it's really not obvious there are some humans working
> there to that take care of this. That and all those bugs that never get
> a reply look really like things are not working well.
>
>> Andrew Morton takes MM bugs and Cc:s them to linux-mm mailing list
>> and then asks for discussion to continue on the mailing list.
>
> Then what use it bugzilla here? Wouldn't it be better for people to go
> straight to the list?
Might as well, yes.
>> We
>
> Who is "we"? We as in "the kernel community"? Or is there actually a
Anyone who is up for it -- yes, mostly "community."
> smaller group of people you are referring to which is actively
> maintaining the list of products and components on bugzilla.kernel.org?
nope.
> Just trying to understand things better here, as there are other things
> that look strange to me and were mentioned in the patch description. For
> example: Why are there only 200 products and components on
> bugzilla.kernel.org (some of them for historic things like the
> ac-kernels) while the MAINTAINERS file has more than 2200 entries?
I wouldn't want a separate entry for each SPI/GPIO/regulator/USB etc.
device. That's just IMO...
>> could/should probably see if we can add more project-specific
>> mailing lists to the automatic reporting
>
> Guess that would mean taking to a lot of maintainers/mailing list admins
> if they are okay with that. Who would do that?
whoever is motivated to do so.
>> -- but probably not LKML.
>> Otherwise some bug reports might never be heard about.
>
> Yeah, agreed.
>
> FWIW: I don't care too much about this whole thing, the whole idea for
> the approach I'm currently driving forward started when I did regression
> tracking in 2017. Back then I noticed quite a lot of bug reports on
> bugzilla.kernel.org never got a single reply, even if they were good and
> looked valid. That's why I brought this forward on the maintainers
> summit (https://lwn.net/Articles/738216/ ) and there it was discussed to
> basically go the route I'm taking currently. But I'm totally find to
> adjust that route if there are good reasons, especially as that
> discussion happened some time ago.
cheers.
--
~Randy
https://people.kernel.org/tglx/notes-about-netiquette
https://www.kernel.org/doc/html/latest/process/submit-checklist.html
Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
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. > 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. (FYI, this person shouldn't be me -- every time I've come to the Foundation, I was asked that the proper way to go about it is through the TAB.) TBH, bug triage sounds like a great kernel developer semi-retirement gig. :) > 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 -- 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. I don't think we should be using this metric as indication that bugzilla doesn't work. > 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. > 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). The sanest approach would be to have a simple web gateway to bug reporting: - 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 - 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 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. -K
Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
Am 11.01.21 um 19:14 schrieb Randy Dunlap:
> On 1/10/21 4:10 AM, Thorsten Leemhuis wrote:
>> * About 66 of those ~200 components will assign bugs to email addresses
>> that look valid, but 125 of them end with @kernel-bugs.osdl.org or
>> @kernel-bugs.kernel.org. Those domains do not exist anymore, mails
>> sent there bounce ('Unrouteable address'). It's possible that the
>> server might be rewriting those domain names and nevertheless
>> delivers new reports and comments by mails to some human; but it
>> seems more like they never get mailed to anyone and thus just linger
>> in the database; no wonder quite a few of bugs filed against such
>> components never get a single reply (see below).
>
> Those @kernel-bugs email addresses should not be a problem:
>
> https://korg.docs.kernel.org/bugzilla.html#real-assignees-vs-virtual-assignees
Ahh, interesting, many many thx. Stupid me also forgot to put Konstantin
on the CC list (I had planned to do that, but forgot when I actually
sent the patch :-/ ), which likely would have pointed be there as well.
> AFAIK, USB bugs go to linux-...@vger.kernel.org,
Those seem to use the approach the link above describes.
> SCSI bugs go to linux-s...@vger.kernel.org.
That's one of the email address that are in the database for real, which
were mentioned in my patch description as 'looking valid':
https://bugzilla.kernel.org/describecomponents.cgi?product=IO%2FStorage
> netdev didn't want bugs sent there automatically IIRC, so a
> human takes care of doing that if warranted.
Ahh, good to know, it's really not obvious there are some humans working
there to that take care of this. That and all those bugs that never get
a reply look really like things are not working well.
> Andrew Morton takes MM bugs and Cc:s them to linux-mm mailing list
> and then asks for discussion to continue on the mailing list.
Then what use it bugzilla here? Wouldn't it be better for people to go
straight to the list?
> We
Who is "we"? We as in "the kernel community"? Or is there actually a
smaller group of people you are referring to which is actively
maintaining the list of products and components on bugzilla.kernel.org?
Just trying to understand things better here, as there are other things
that look strange to me and were mentioned in the patch description. For
example: Why are there only 200 products and components on
bugzilla.kernel.org (some of them for historic things like the
ac-kernels) while the MAINTAINERS file has more than 2200 entries?
> could/should probably see if we can add more project-specific
> mailing lists to the automatic reporting
Guess that would mean taking to a lot of maintainers/mailing list admins
if they are okay with that. Who would do that?
> -- but probably not LKML.
> Otherwise some bug reports might never be heard about.
Yeah, agreed.
FWIW: I don't care too much about this whole thing, the whole idea for
the approach I'm currently driving forward started when I did regression
tracking in 2017. Back then I noticed quite a lot of bug reports on
bugzilla.kernel.org never got a single reply, even if they were good and
looked valid. That's why I brought this forward on the maintainers
summit (https://lwn.net/Articles/738216/ ) and there it was discussed to
basically go the route I'm taking currently. But I'm totally find to
adjust that route if there are good reasons, especially as that
discussion happened some time ago.
Ciao, Thorsten
Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
On 1/10/21 4:10 AM, Thorsten Leemhuis wrote:
> * About 66 of those ~200 components will assign bugs to email addresses
> that look valid, but 125 of them end with @kernel-bugs.osdl.org or
> @kernel-bugs.kernel.org. Those domains do not exist anymore, mails
> sent there bounce ('Unrouteable address'). It's possible that the
> server might be rewriting those domain names and nevertheless
> delivers new reports and comments by mails to some human; but it
> seems more like they never get mailed to anyone and thus just linger
> in the database; no wonder quite a few of bugs filed against such
> components never get a single reply (see below).
Those @kernel-bugs email addresses should not be a problem:
https://korg.docs.kernel.org/bugzilla.html#real-assignees-vs-virtual-assignees
AFAIK, USB bugs go to linux-...@vger.kernel.org,
SCSI bugs go to linux-s...@vger.kernel.org.
netdev didn't want bugs sent there automatically IIRC, so a
human takes care of doing that if warranted.
Andrew Morton takes MM bugs and Cc:s them to linux-mm mailing list
and then asks for discussion to continue on the mailing list.
We could/should probably see if we can add more project-specific
mailing lists to the automatic reporting -- but probably not LKML.
Otherwise some bug reports might never be heard about.
--
~Randy
[PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
The bugtracker on kernel.org is not working very well and might be a
disservice to the community, as discussed on the maintainers summit 2017
and explained below in detail. For most of the kernel it was never the
preferred place to report issues anyway, as the MAINTAINERS file and the
recently added text Documentation/admin-guide/reporting-issues.rst show.
Hence, remove the two points in the kernel's English documentation that
suggest submitting all sorts of bugs in bugzilla.kernel.org. That gets
rid of known inconsistencies with
Documentation/admin-guide/reporting-issues.rst, which is the reason for
one 'this needs further discussion' warning in there. Hence, remove that
warning as well to make the approach it describes the official one. A
few files in the Documentation continue referring to bugzilla.kernel.org
and sometimes even suggest filing issues there, but those references are
fine for now (see below for details).
Why bugzilla.kernel.org isn't working well
==
Find below the good, the bad and the ugly aspects of
bugzilla.kernel.org.
The good
Bugzilla.kernel.org is useful tool sometimes:
* About 15 of the ~2225 section entries in Linux's MAINTAINERS file
point to bugzilla.kernel.org as the official place to report bugs.
from a brief look it seems the developers of those areas take care of
issues filed in the bug tracker; sometimes they even file bugs there
themselves to keep track of things.
* For a few other subsystems the bug tracker also works as intended: the
maintainer gets reports and comments by mail. Some act upon those.
Gregkh is one of those, who often replies with standard text like "you
should report this to your distro" or "Please report this to the
following mailing list instead".
* The bug tracker sometimes brings users together: someone files a bug
which other users find and join; the users sometimes help each other
and occasionally even manage to get the right developers involved,
even in cases where those don't get a copy of the report by mail.
* It's a place where users can upload files they don't want or can't
send to mailing lists.
The bad
---
The list of products and components in bugzilla.kernel.org is widely
incomplete, outdated in sometimes plain wrong. The same is true for the
list of default assignees and the email addresses to which newly filed
reports get send to.
This leads to several problems. To see some of them one needs to look
closer at the products and components, for example by browsing the web
(https://bugzilla.kernel.org/describecomponents.cgi) or by using the
REST interface to get it as JSON
(https://bugzilla.kernel.org//rest/product?type=accessible [to get the
email addresses one needs to provide login credentials as well]).
That JSON output will list about 20 products with nearly 200 components.
* The majority of the ~2225 section entries and subsystems listed in
the MAINTAINERS file have no corresponding entry in bugzilla, hence
it's not a tool to contact the people users need to contact in case
of problems.
* About 66 of those ~200 components will assign bugs to email addresses
that look valid, but 125 of them end with @kernel-bugs.osdl.org or
@kernel-bugs.kernel.org. Those domains do not exist anymore, mails
sent there bounce ('Unrouteable address'). It's possible that the
server might be rewriting those domain names and nevertheless
delivers new reports and comments by mails to some human; but it
seems more like they never get mailed to anyone and thus just linger
in the database; no wonder quite a few of bugs filed against such
components never get a single reply (see below).
The ugly
Bugzilla.kernel.org might look like the official place to report all
sorts of kernel bugs, but it was never. That itself would be just bad,
what makes it ugly is this:
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.'
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.
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.
(¹) bugs created between 2020-11-21 and 2020-12-05 23:59:59; that's
about one week before the merge window of 5
