Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org

[Randy Dunlap <rdunlap@infradead.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-usb@vger.kernel.org,
> 
> Those seem to use the approach the link above describes.
> 
>> SCSI bugs go to linux-scsi@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