archive mirror
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <>
To: Thorsten Leemhuis <>
Cc: Jonathan Corbet <>,
	Randy Dunlap <>,,
Subject: Re: [PATCH v1 (RFC)] docs: discourage users from using
Date: Mon, 11 Jan 2021 14:48:22 -0500	[thread overview]
Message-ID: <20210111194822.4kvl2tx24anyu23k@chatter.i7.local> (raw)
In-Reply-To: <>

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

(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 admins. They are doing a good job at keeping
> the 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 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 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.


  parent reply	other threads:[~2021-01-11 19:49 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
2021-01-11 19:48 ` Konstantin Ryabitsev [this message]
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 \
    --in-reply-to=20210111194822.4kvl2tx24anyu23k@chatter.i7.local \ \ \ \ \ \ \

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