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: <3ee2a3d6-5711-3240-c181-cd34426932ed@gmx.com>
Date:   Thu, 6 Oct 2022 07:56:24 +0000
MIME-Version: 1.0
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"
Cc:     ksummit <ksummit-discuss@lists.linuxfoundation.org>,
        workflows@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
        "regressions@lists.linux.dev" <regressions@lists.linux.dev>
References: <aa876027-1038-3e4a-b16a-c144f674c0b0@leemhuis.info>
 <20221004175354.bfvg3vhfqch35ib5@meerkat.local>
From:   "Artem S. Tashkinov" <aros@gmx.com>
In-Reply-To: <20221004175354.bfvg3vhfqch35ib5@meerkat.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
To:     unlisted-recipients:; (no To-header on input)
Precedence: bulk


On 10/4/22 17:53, Konstantin Ryabitsev wrote:
> 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 idea=
s
>> 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 subsyste=
m
>> didn't fully commit to look into newly submitted reports. (3) Change th=
e
>> 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 establish=
ed).
> 3. Establish and maintain a team of designated triage people who are wil=
ling
>     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 b=
ug
>     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.kerne=
l.org
>     and automatically add comments/links when it sees the bug mentioned
>     elsewhere.
>
> I'm happy to take care of everything bot-related (apparently, programmin=
g 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 alread=
y
> using these funds for someone to help him with all the other tasks).
>
> Does that sound like a plan for everyone?

This looks fabulous.

Except, I'd love to let users have an option of submitting bugs to the
component they specify manually.

(I've removed a ton of people from CC because my email provider
absolutely hates when I send emails to many addresseses simultaneously -
my account was completely blocked for five days while I tried hard to
reach support).