Date:   Mon, 11 Jan 2021 14:48:22 -0500
From:   Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>
Cc:     Jonathan Corbet <corbet@....net>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 (RFC)] docs: discourage users from using
 bugzilla.kernel.org

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

Powered by blists - more mailing lists