archive mirror
 help / color / mirror / Atom feed
From: Randy Dunlap <>
To: Thorsten Leemhuis <>,
	Jonathan Corbet <>
Subject: Re: [PATCH v1 (RFC)] docs: discourage users from using
Date: Mon, 11 Jan 2021 15:42:28 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 or
>>> 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:
> 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,
> Those seem to use the approach the link above describes.
>> SCSI bugs go to
> That's one of the email address that are in the database for real, which
> were mentioned in my patch description as 'looking valid':
>> 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


> 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
> (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
> never got a single reply, even if they were good and
> looked valid. That's why I brought this forward on the maintainers
> summit ( ) 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.


  reply	other threads:[~2021-01-12  0:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-10 12:10 [PATCH v1 (RFC)] docs: discourage users from using Thorsten Leemhuis
2021-01-11 18:14 ` Randy Dunlap
2021-01-11 18:55   ` Thorsten Leemhuis
2021-01-11 23:42     ` Randy Dunlap [this message]
2021-01-12 17:34       ` Thorsten Leemhuis
2021-01-11 19:48 ` Konstantin Ryabitsev
2021-01-12 19:09   ` Thorsten Leemhuis
2021-01-13 11:17     ` Jani Nikula
2021-01-14 19:18       ` Konstantin Ryabitsev
2021-11-05 14:36 ` Artem S. Tashkinov
2021-11-05 14:42   ` Matthew Wilcox
2021-11-05 14:59     ` Artem S. Tashkinov
2021-11-08 11:43   ` Jani Nikula
2021-11-08 12:03     ` Artem S. Tashkinov
2021-11-08 13:00       ` Jani Nikula
2021-11-08 13:17         ` Artem S. Tashkinov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).