archive mirror
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <>
To: Randy Dunlap <>, Jonathan Corbet <>
Subject: Re: [PATCH v1 (RFC)] docs: discourage users from using
Date: Tue, 12 Jan 2021 18:34:18 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

>> 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...

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 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, as otherwise things will just stay as they
are, which IMHO is a bad idea with the state of things.

Ciao, Thorsten

  reply	other threads:[~2021-01-12 17:35 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
2021-01-12 17:34       ` Thorsten Leemhuis [this message]
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).