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;
Date:   Tue, 4 Oct 2022 13:53:54 -0400
From:   Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To:     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: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"
Message-ID: <20221004175354.bfvg3vhfqch35ib5@meerkat.local>
References: <aa876027-1038-3e4a-b16a-c144f674c0b0@leemhuis.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <aa876027-1038-3e4a-b16a-c144f674c0b0@leemhuis.info>
Precedence: bulk

On Thu, Sep 29, 2022 at 01:19:24PM +0200, Thorsten Leemhuis wrote:
> 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.

Here's my counter-plan, which builds on top of yours.

1. Create a Kernel/Kernel product that acts as a starting point for all bug
   submissions.
2. Create and maintain a mapping from MAINTAINER subsystem entries to
   Product/Component categories in Bugzilla (the scheme to be established).
3. Establish and maintain a team of designated triage people who are willing
   to look at incoming bugs to either:

   a. quick-close them as non-actionable (tainted kernel, distro kernel, spam)
   b. obtain missing information from the submitter as necessary
   c. figure out the correct component to assign, to the best of their ability
   d. set a "triaged" flag

4. a backend monitoring bot will track all bug changes and, when it sees a bug
   get the "triaged" state, it will:

   a. create a useful bug summary from all bug comments
   b. figure out who to notify based on the mapping (see #2 above)
   c. send out the email to everyone identified

5. the same backend monitoring bot will track responses and update the bug
   comments as needed; any comments added via the bugzilla site will be
   similarly sent out as follow-up messages.

6. the bot can also monitor commits and other discussions via lore.kernel.org
   and automatically add comments/links when it sees the bug mentioned
   elsewhere.

I'm happy to take care of everything bot-related (apparently, programming bots
is what I do now -- I just wish it was the cool and glamorous kind).

As I have stated multiple times, the hard part will be keeping a team of
people who are willing to do the bug triage work, but maybe we can start with
Greg KH using his intern funds to hire someone (assuming he's not already
using these funds for someone to help him with all the other tasks).

Does that sound like a plan for everyone?

-K