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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ee2a3d6-5711-3240-c181-cd34426932ed@gmx.com>
Date:   Thu, 6 Oct 2022 07:56:24 +0000
From:   "Artem S. Tashkinov" <aros@....com>
To:     unlisted-recipients:; (no To-header on input)
Cc:     ksummit <ksummit-discuss@...ts.linuxfoundation.org>,
        workflows@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"



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 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?

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).