Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <aa876027-1038-3e4a-b16a-c144f674c0b0@leemhuis.info>
Date:   Thu, 29 Sep 2022 13:19:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Content-Language: en-US, de-DE
To:     Konstantin Ryabitsev <konstantin@linuxfoundation.org>
From:   Thorsten Leemhuis <linux@leemhuis.info>
Cc:     "Artem S. Tashkinov" <aros@gmx.com>,
        ksummit <ksummit-discuss@lists.linuxfoundation.org>,
        workflows@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "regressions@lists.linux.dev" <regressions@lists.linux.dev>
Subject: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi!

TLDR: Core Linux kernel developers are unhappy with the state of
bugzilla.kernel.org; to improve things I plan to change a few important
aspects of its configuration, unless somebody comes up with better ideas
to tackle current problems: (1) Create a catch-all product making it
totally obvious to submitters that likely nobody will look into the
ticket. (2) Remove or hide all products & components where the subsystem
didn't fully commit to look into newly submitted reports. (3) Change the
text on the front page to make it clear that most kernel bug reports
need to be sent by mail.

I recently brought the state of bugzilla.kernel.org up for discussion on
the kernel summit and the kernel maintainers summit in sessions about my
regression tracking efforts. Long story short and rough: in both
sessions attendees were quite unhappy about the current state and wanted
things to change for the better. As I brought that topic up, I guess I
have to get things rolling now.

But before getting into the details, a quick & rough reminder about the
current state of bugzilla.kernel.org:

 * The server and the software running on it are well maintained by the
the infrastructure team (Konstantin et al.); many thx for this!

 * Products, components, default assignees, et al. OTOH are heavily
outdated, incomplete, or wrong: maintaining this is not the job of the
infrastructure team and nobody else has stepped up to take care of this
(for a few more details see:
https://lore.kernel.org/lkml/20220420163223.kz32qomzj3y4hjj5@nitro.local/).

 * To the best of my knowledge bugzilla.kernel.org was never really
sanctioned as the official place to report all sorts of kernel bugs:
only 20 (most of them from the area of ACPI/PM and PCI) out of ~2500
entries in MAINTAINERS currently tell users to report issues there; most
other subsystems just mention email contacts, a few (like the DRM
developers) point reporters to external bugtrackers.

 * Developers of subsystems committed to the bug-tracker afaics usually
react to reports submitted in bugzilla.kernel.org. A few other
developers & subsystems keep an eye on reports, too; some do this
directly, others rely on bugzilla forwarding reports for certain
products/components by mail to the subsystem's mailing list. Quite some
or a lot of tickets are not forwarded to any developer or mailing list
at all.

 * In the end lots of bug and regression reports (even good ones!) never
get a reply from a developer, as a brief analysis of mine showed
(https://lore.kernel.org/lkml/6808cd17-b48c-657d-de60-ef9d8bfa151e@leemhuis.info/
). I at least currently try to work a bit against this by briefly
looking at each new report and forwarding any by mail that looks like a
regression worth forwarding (I ignore everything else). Artem S.
Tashkinov also looks into some (all?) reports and tries to help reporters.

The sessions on kernel summit and the kernel maintainers summit
discussed the current state only for a few minutes. It's hard to
summarize these discussions, but let me try to mention the aspects that
are important for now:

 * In both sessions members of the audience seemed pretty unhappy to me
about the current state of things.

 * In the kernel summit sessions (recording:
https://youtu.be/e2SZoUPhDRg?t=5370 ) Len Brown stated that he and
fellow ACPI/PM developers rely on bugzilla.kernel.org and would need
some replacement if it's decommissioned.

 * On the maintainers summit (see the last section of
https://lwn.net/Articles/908324/ for a brief write-up that coined the
term "Bugzilla blues") someone brought up the upstream development of
bugzilla the software seems to be dead; there was not even one strong
advocate for bugzilla.kernel.org and the general vibe tented into the
direction of "let's get rid of it". But it was also mentioned that
bugzilla.kernel.org does something useful which will need a replacement:
a place where reporters can upload big files needed for debugging problems.

In the end that made me settle on this plan of action:

 1. Finding a replacement for bugzilla will take a while, so for now
let's try to reduce some of its aspects that are bothering people:

  1a. Create a new product/component that can act as a catch-all bug,
but makes it pretty clear that nobody might see the report because it's
not forwarded to anyone. People can use it to upload files for debugging
and link to them in mailed reports. People unable or unwilling to report
issues my mail (see 1c) could use it to submit issues, too. The outcome
then is the same as before, but at least people were told upfront about
the likely outcome; it also gives users a chance to help each other or
to coordinate before properly reporting an issue.

  1b. Go through the list of products and components and hide or remove
*all* where the subsystem didn't fully commit to look into newly
submitted reports. Minimum requirements to remain listed will be along
these lines: subsystem mentions bugzilla.kernel.org in MAINTAINERS or a
developer listed in MAINTAINERS is one of the default assignees in
bugzilla. Subsystems where bugzilla forwards mails to a mailing list can
remain listed as well, if the recent history shows the developers look
into newly filed bugs. I'll use my best judgment in the transition
process and will file "anyone listening?" bugs if in a doubt.

  1c. Make it obvious on the front-page of bugzilla.kernel.org that most
kernel developers want bug reports to be submitted by mail; mention the
subsystems that accept reports there and point to the catch-all bug (see
1a) as a last straw.

 2. See if everybody is happy with the new state for the time being; if
not further fine-tune things or speed up step (3).

 3. Work out what we want as replacement.

Anyone any comments on this or helpful ideas how to make things even
better? Otherwise, I'll in a week or two get down and start working on
realizing the points listed under step (1).

Ciao, Thorsten