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.11 started and 2 1/2 weeks
before Christmas
Who's not to blame
------------------
For the sake of this commit it's irrelevant at all who's to blame for
the state of bugzilla.kernel.org; it for sure was set up with good
intentions, it just didn't work out very well in the end. The situations
just needs to be improved, ideally quickly; blaming it on someone isn't
helping at all.
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.
Why not fix it?
---------------
It's well known for years now that bugzilla.kernel.org is not working
that well, but nobody ever stepped up to improve the situation. Maybe
this commit gets something rolling. If that's the case this change can
be reverted. For now the change is an improvement that was agreed on
during the maintainers summit 2017 in a session discussion regression
tracking (https://lwn.net/Articles/738216/).
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.
Where bugzilla.kernel.org still gets mentioned
==============================================
After this commit, a few places in the kernel's documentation continue
to mention bugzilla.kernel.org:
* admin-guide/reporting-issues.rst -- it discourages people from filing
issues there, but mention it's better to file a bug there than not
reporting it at all (that part is inspired from a similar section in
admin-guide/reporting-bugs.rst). The file also mentions the bug tracker
as a good place to upload big files which should be keep available for
years (dmesg output, config files, …).
* admin-guide/reporting-bugs.rst -- it still mentions bugzilla in a
broader sense a few times. There is also one place where it suggests
filing any sort of issues in bugzilla.kernel.org, which will be
addresses by a different patch, as it touches another aspect that and
thus better discussed separately. The whole file will vanish anyway
once Documentation/admin-guide/reporting-issues.rst is considered
fully ready.
* admin-guide/cifs/todo.rst -- just mentions it as a place to look for
'known bugs', which seems fine, as the CIFS maintainers are among
those that seem to keep an eye on bugzilla.kernel.org.
* bpf/bpf_devel_QA.rst -- discourages people from filing issues there.
* process/code-of-conduct-interpretation.rst -- just mentions it as an
example for 'bug tracking tools' with isn't particular concerning.
* sound/alsa-configuration.rst and sound/hd-audio/notes.rst -- they
mention it as a place to file bugs. Looks like at least some are
looked at, thus leave this as it is for now.
* A few translations still mention the bug tracker; they hopefully
notice this change and follow suit.
Signed-off-by: Thorsten Leemhuis <[email protected]>
---
v1 (RFC):
- Just sent to a 'small' audience (linux-docs, Jon, Randy, LKML); once
it got some comments the plan is to send this to a bigger audience,
including Gregkh (who's listed as maintainer for
Documentation/process/howto.rst) and ksummit-discuss (which is the
best way to contact the core developers; and it's a follow up to a
maintainer summit discussion anyway).
Ciao, Thorsten
---
Documentation/admin-guide/reporting-bugs.rst | 7 +++----
.../admin-guide/reporting-issues.rst | 20 -------------------
Documentation/process/howto.rst | 20 +++++++++----------
3 files changed, 13 insertions(+), 34 deletions(-)
diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
index 409fa91d7495..284de0314b5d 100644
--- a/Documentation/admin-guide/reporting-bugs.rst
+++ b/Documentation/admin-guide/reporting-bugs.rst
@@ -48,11 +48,10 @@ Identify who to notify
----------------------
Once you know the subsystem that is causing the issue, you should send a
-bug report. Some maintainers prefer bugs to be reported via bugzilla
-(https://bugzilla.kernel.org), while others prefer that bugs be reported
-via the subsystem mailing list.
+bug report. Most of the maintainers prefer them to be reported by mail,
+but a few of them rely on bug trackers.
-To find out where to send an emailed bug report, find your subsystem or
+To find out where to send or file your bug report, find your subsystem or
device driver in the MAINTAINERS file. Search in the file for relevant
entries, and send your bug report to the person(s) listed in the "M:"
lines, making sure to Cc the mailing list(s) in the "L:" lines. When the
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index 5cbb1b5f4a52..147b9bb7d320 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -526,26 +526,6 @@ example above does not have such a line. That is the case for most sections, as
Linux kernel development is completely driven by mail. Very few subsystems use
a bug tracker, and only some of those rely on bugzilla.kernel.org.
-
-.. note::
-
- FIXME: The old text took a totally different approach to bugzilla.kernel.org,
- as it mentions it as the place to file issue for people that don't known how
- to contact the appropriate people. The new one mentions it rarely; and when
- it does like here, it warns users that it's often the wrong place to go.
-
- This approach was chosen as the main author of this document noticed quite a
- few users (or even a lot?) get no reply to the bugs they file in bugzilla.
- That's kind of expected, as quite a few (many? most?) of the maintainers
- don't even get notified when reports for their subsystem get filed there. And
- not getting a single reply to report is something that is just annoying for
- users and might make them angry. Improving bugzilla.k.o would be an option,
- but on the kernel and maintainers summit 2017 it was agreed on to first go
- this route (sorry it took so long): it's easier to achieve and less
- controversial, as putting additional burden on already overworked maintainers
- is unlikely to get well received.
-
-
In this and many other cases you thus have to look for lines starting with
'Mail:' instead. Those mention the name and the email addresses for the
maintainers of the particular code. Also look for a line starting with 'Mailing
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 7a5c105e34d4..5fd695a0b363 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -342,16 +342,10 @@ Adventurous testers are very welcome to runtime-test the linux-next.
Bug Reporting
-------------
-https://bugzilla.kernel.org is where the Linux kernel developers track kernel
-bugs. Users are encouraged to report all bugs that they find in this
-tool. For details on how to use the kernel bugzilla, please see:
-
- https://bugzilla.kernel.org/page.cgi?id=faq.html
-
The file 'Documentation/admin-guide/reporting-issues.rst' in the main kernel
-source directory has a good template for how to report a possible kernel bug,
-and details what kind of information is needed by the kernel developers to help
-track down the problem.
+source directory describes how to report a possible kernel bug, and details
+what kind of information is needed by the kernel developers to help track
+down the problem.
Managing bug reports
@@ -364,7 +358,13 @@ improve your skills, and other developers will be aware of your presence.
Fixing bugs is one of the best ways to get merits among other developers,
because not many people like wasting time fixing other people's bugs.
-To work in the already reported bug reports, go to https://bugzilla.kernel.org.
+To work on already reported bug reports, find a subsystem you are interested in
+and check existing reports for one where you want to help. You find such
+reports in the archives of the place where reports for the particular subsystem
+need to be sent to, which is listed in the MAINTAINERS file; often it will be a
+mailing list, rarely a bugtracker. You may also consider checking
+https://bugzilla.kernel.org. Only a handful of kernel subsystems actually use it
+actively, but bugs for other subsystems get filed there nevertheless.
Mailing lists
--
2.29.2
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 [email protected],
SCSI bugs go to [email protected].
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
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 [email protected],
Those seem to use the approach the link above describes.
> SCSI bugs go to [email protected].
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
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
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 [email protected],
>
> Those seem to use the approach the link above describes.
>
>> SCSI bugs go to [email protected].
>
> 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
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
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
On Tue, 12 Jan 2021, Thorsten Leemhuis <[email protected]> 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 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
--
Jani Nikula, Intel Open Source Graphics Center
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
On 11/5/21 14:42, Matthew Wilcox wrote:
> On Fri, Nov 05, 2021 at 02:36:51PM +0000, Artem S. Tashkinov wrote:
>> Hello,
>>
>> Let me express an utter dissatisfaction and even contempt for this proposal.
>
> Thank you for volunteering to take over administration of
> bugzilla.kernel.org. Can you lay out your plans for making kernel
> developers care about it?
>
Last time I checked the Linux foundation is not exactly living from hand
to mouth and has enough financial backing from major corporations.
Is this really about funding?
Regards,
Artem
Hello,
Let me express an utter dissatisfaction and even contempt for this proposal.
1. Absolute most open source projects are managed via bug trackers, I
see no reason the Linux kernel should be exempt
2. LKML has historically created/used for for posting patches and
discussing kernel features. Of course, major bugs have been discussed
and resolved as well but mostly among _core_ Linux hackers who are
_subscribed_ to it and _participate_ in it which is _not_ the case for
absolute most kernel developers nowadays.
2. Even though many kernel maintainers and subsystems express their
desire to manage bug reports via e-mail it's an utterly preposterous,
nonworking and broken idea for the following reasons:
2.1 Tons of messages in various kernel related mailing lists have zero
replies and are not acted upon in any way or shape
2.2 There's no sense of accountability, no way to see what are the
current issues, what's resolved or not
2.3 Users have an extremely hard time looking for bug reports which are
spread along God knows where
2.4 It's impossible to follow up on such messages except when you were
subscribed to the original mailing list, IOW just impossible
2.5 It's extremely difficult to collaborate since e-mail totally sucks
when it comes to long discussions.
Consider this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Over a hundreds of messages, multiple attachments, a flow of ideas and
patches - how on Earth this can possibly be replicated using email? Why
does pretty much no other project aside from maybe Debian has this
peculiar workflow?
2.6 You're under the impression that user will read this wonderful
document. They will not, they will google for "report bug linux kernel"
and find bugzilla.kernel.org
2.7 If you venture to work as a kernel hacker you're expected to be
_responsible_ for your code. If you submit a patch and disappear that's
going to be more a disservice to the community rather than actual help.
---
Let me continue.
Here's something which is really bad for bugzilla.kernel.org:
People _continue_ to file bug reports for graphics drivers in Linux and
we don't even have proper components for it, only
Video (AGP) - What? AGP has been dead for a decade.
Video (DRI - Non Intel) - what? Isn't it an X.org's feature, not kernel's?
Video (Other)
This is a complete and total clusterjoy.
I don't think it's too difficult:
1) At least update Video components, let's say, have Intel, AMD, Nouveau
and Other - there's a ton more but these will suffice. Most others are
for mobile/embedded and to be honest their users are unlikely to ever
touch this bugzilla.
2) To integrate the first three with https://gitlab.freedesktop.org/drm/
and automatically crosspost over there.
3) Someone has to actually read all the bug reports and check whether
they are relevant, filed properly, filed under the proper category and
whether they should be closed.
4) And what's with the front page which says to use Distros bugzillas? I
smell some BS in this statement because among all distros maybe RedHat
and Ubuntu have the people to deal with kernel issues, and all others
simply don't in any capacity. Bugs filed in distros bug trackers will
linger for ages, get zero attention (it's my experience with Fedora and
even RHEL) and be closed since _no one cares_ and no one is experienced
enough.
I really hate how this bugzilla is treated as an afterthought which no
one really cares about. If no one cares, why does it exist in the first
place? Let's shut it down then. Let's move to mailing lists and create a
total mayhem of lack of accountability. "Bugs? Sorry, I've had no time
to read emails".
If it exists and serves some purpose, why Products and Components are
stuck as if they were created in 1995, not in 2021?
AFAIK kernel.org is a The Linux Foundation project. The organization is
heavily sponsored by tons of companies. It would be great if we had a
person actually invested in bugzilla.kernel.org
---
Best regards,
Artem
On Fri, Nov 05, 2021 at 02:36:51PM +0000, Artem S. Tashkinov wrote:
> Hello,
>
> Let me express an utter dissatisfaction and even contempt for this proposal.
Thank you for volunteering to take over administration of
bugzilla.kernel.org. Can you lay out your plans for making kernel
developers care about it?
On Fri, 05 Nov 2021, "Artem S. Tashkinov" <[email protected]> wrote:
> Let me continue.
>
> Here's something which is really bad for bugzilla.kernel.org:
>
> People _continue_ to file bug reports for graphics drivers in Linux and
> we don't even have proper components for it, only
>
> Video (AGP) - What? AGP has been dead for a decade.
> Video (DRI - Non Intel) - what? Isn't it an X.org's feature, not kernel's?
> Video (Other)
>
> This is a complete and total clusterjoy.
FWIW, for Intel graphics (i915) we don't want any bug reports at
bugzilla.kernel.org. We've migrated away more than five years ago. The
"Video (DRI - Intel)" component was closed for new bugs around that
time, the description points at freedesktop.org as does MAINTAINERS:
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
B: https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On Mon, 08 Nov 2021, "Artem S. Tashkinov" <[email protected]> wrote:
> It does *not* help one bit that we have different bug trackers and
> mailing lists for a *single* component which is the kernel. No other
> software project under the sun makes the user rack their head trying to
> understand how and where to post bug reports.
I suppose the kernel is a single component only from a fairly narrow
user centric view. Sure, it would be nice, from a user perspective, to
have a single bug tracker for everything. But behind the scenes, the
kernel development community is so broad and fragmented it's basically
impossible to get people to agree on a tracker that would suit everyone
and that everyone would use. Furthermore, there are users that insist on
reporting bugs on their own terms anyway, refusing to sign up to any
trackers.
Arguably "the single bug tracker" most users should report their kernel
problems for triage first is their distro bug tracker.
> Can we shut down bugzilla.kernel.org completely? In its current form
> it's nothing but disgrace.
Works for me, ymmv.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On 11/8/21 11:43, Jani Nikula wrote:
> On Fri, 05 Nov 2021, "Artem S. Tashkinov" <[email protected]> wrote:
>> Let me continue.
>>
>> Here's something which is really bad for bugzilla.kernel.org:
>>
>> People _continue_ to file bug reports for graphics drivers in Linux and
>> we don't even have proper components for it, only
>>
>> Video (AGP) - What? AGP has been dead for a decade.
>> Video (DRI - Non Intel) - what? Isn't it an X.org's feature, not kernel's?
>> Video (Other)
>>
>> This is a complete and total clusterjoy.
>
> FWIW, for Intel graphics (i915) we don't want any bug reports at
> bugzilla.kernel.org. We've migrated away more than five years ago. The
> "Video (DRI - Intel)" component was closed for new bugs around that
From my initial message:
---
2.6 You're under the impression that users will read this wonderful
document (reporting-bugs.rst). They will *not*, they will google for
"report bug linux kernel" and find bugzilla.kernel.org
2) To integrate the first three with https://gitlab.freedesktop.org/drm/
and automatically crosspost over there.
---
It does *not* help one bit that we have different bug trackers and
mailing lists for a *single* component which is the kernel. No other
software project under the sun makes the user rack their head trying to
understand how and where to post bug reports.
And then like I've mentioned earlier:
---
2.1 Tons of messages in various kernel related mailing lists have zero
replies and are not acted upon in any way or shape
2.2 There's no sense of accountability, no way to see what are the
current issues, what's resolved or not
2.3 Users have an extremely hard time looking for bug reports which are
spread along God knows where
2.4 It's impossible to follow up on such messages except when you were
subscribed to the original mailing list, IOW just impossible
2.5 It's extremely difficult to collaborate since e-mail totally sucks
when it comes to long discussions.
---
The Linux kernel bug reporting process is a complete clusterfuck and it
looks like no one cares at all. The consensus is "the harder it is, the
better" since unreported bugs means less work, accountability and
responsibility.
The fact that no one from FSF has replied to any of my messages is a
further confirmation. Budget ~$2 million in FY 2019. I guess two million
bucks are not enough to take proper care of the most important FSF project.
Can we shut down bugzilla.kernel.org completely? In its current form
it's nothing but disgrace.
> time, the description points at freedesktop.org as does MAINTAINERS:
>
> INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
> B: https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
>
>
> BR,
> Jani.
>
>
On 11/8/21 13:00, Jani Nikula wrote:
> On Mon, 08 Nov 2021, "Artem S. Tashkinov" <[email protected]> wrote:
>> It does *not* help one bit that we have different bug trackers and
>> mailing lists for a *single* component which is the kernel. No other
>> software project under the sun makes the user rack their head trying to
>> understand how and where to post bug reports.
>
> I suppose the kernel is a single component only from a fairly narrow
> user centric view. Sure, it would be nice, from a user perspective, to
> have a single bug tracker for everything. But behind the scenes, the
> kernel development community is so broad and fragmented it's basically
> impossible to get people to agree on a tracker that would suit everyone
> and that everyone would use. Furthermore, there are users that insist on
> reporting bugs on their own terms anyway, refusing to sign up to any
> trackers.
>
> Arguably "the single bug tracker" most users should report their kernel
> problems for triage first is their distro bug tracker.
>
>> Can we shut down bugzilla.kernel.org completely? In its current form
>> it's nothing but disgrace.
>
> Works for me, ymmv.
Linux hackers probably don't need anything at all, I'm talking about
average people.
From the Official Debian documentation (
https://wiki.debian.org/DebianKernelReportingBugs ):
> "If an oops is reproducible on latest please notify upstream via
email. Another way to notify upstream is to file a bug in
https://bugzilla.kernel.org/".
Lots of bug reports about the kernel in the Debian bug tracker see this:
> "Report upstream".
Which is the opposite of what you can see at bugzilla.kernel.org
It's quite amazing that absolute most distros except maybe RedHat and
Ubuntu have zero people who can actually resolve kernel bugs yet the
kernel bugzilla denies the option of using it.
Anyways, looks like all the responsible people have their ears shut, so
let's leave everything as it is.