Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"

[Thorsten Leemhuis]

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

So, merge window is over. To avoid any doubt, I'd now like to get a
clarification what the outcome of this discussion actually is.

FWIW, as most of you likely know, lwn.net has a write-up of this thread:
https://lwn.net/Articles/910740/

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

Is this the agreed on path forward by silent agreement? And if so: who
will actually shepherd this? I just wonder, as it sounded to me that
Konstantin would be happy to take care of the bot-related stuff, but
leave the rest to somebody else.

Or do we have two proposals on the table that are kind of deadlocked so
that nothing will happen until the next maintainers summit, where things
like this are usually discussed and a way forward agreed on? Then the
ugly situation with bugzilla.kernel.org would continue for afaics at
least 11 more months, which I'd call "unfortunate". :-/

Ciao, Thorsten

> 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