From: Thorsten Leemhuis <linux@leemhuis.info>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: "workflows@vger.kernel.org" <workflows@vger.kernel.org>,
Linux kernel regressions list <regressions@lists.linux.dev>
Subject: Re: Bugbot for all kernel bugs?
Date: Sat, 15 Jul 2023 13:30:06 +0200 [thread overview]
Message-ID: <8c18ee62-2647-92f1-6430-5af650f8bc11@leemhuis.info> (raw)
In-Reply-To: <20230714-zion-margin-natasha-a66ce1@meerkat>
On 14.07.23 22:19, Konstantin Ryabitsev wrote:
> On Thu, Jul 13, 2023 at 01:45:58PM +0200, Thorsten Leemhuis wrote:
>>> So, we can't easily do "enable for all the bugs" because the bot was written
>>> with the idea that it would be invoked per-component. Is there a bugzilla
>>> component (and a matching mailing list) that you have in mind for the bot?
>>
>> Ugh. :-/ Well, as you can see from a quick search like
>> https://lore.kernel.org/all/?q=%28nq%3A%22noticed+a+regression+report+in+bugzilla.kernel.org%22+f%3Aleemhuis%29+OR+%28nq%3A%22I+notice+a+regression+report+on+Bugzilla%22+f%3Asanjaya%29
>> we have to deal will bug reports for many different components. So it
>> would be great if it could be enabled for all products/components, except:
>>
>> * all components from the product categories "Alternate Trees",
>> "Backports project", "Documentation", "kernel.org", and "Tools"
>>
>> * "Bug Tracker", "klibc/kinit", "module-init-tools", and "Spam" from the
>> product category "Other"
>>
>> There might be a few more that are obsolete hidden in the other products
>> categories (like "PS3" in "Platform Specific/Hardware" or "lguest" in
>> "Virtualization")
>>
>> Did I say "Ugh" already? Ohh, seems I did. :-/
>>
>> So how do you suggest to move forward
>
> One of the main drives behind bugbot was to eliminate as many components as
> possible and just let people file bugs under "Linux/Kernel". The "bug
> wrangler" people would then do initial triage
So bugs that people file for products/components that will remain won't
get triage? Wondering if that is a wise idea, but whatever, that is
nothing I'd consider a blocker, so let see.
> and set the "Subsystem" field to
> match an entry from MAINTAINERS. Then, they would set the "bugbot" flag to "+"
> and let the bot do the rest, fully bridging bugzilla with the mailing lists.
>
> So, in my perfect little world we'd:
>
> 1. identify products/components that we can abandon right away and close them
> for new bug entry
> 2. identify the "bug wranglers" who can do the initial triage and grant them
> the power to set the "bugbot" flag
> 3. catch and fix the bugs
>
> We can start with #1 if everyone is happy with this course of action.
Hmmm, that's fine with me, but all that will take some time, hence allow
me to ask: if there a downside (much work?) to simply enable it now for
lots of other products/components until 1 and 2 are realized?
Ciao, Thorsten
prev parent reply other threads:[~2023-07-15 11:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-10 17:28 Bugbot for all kernel bugs? Thorsten Leemhuis
2023-07-11 20:43 ` Konstantin Ryabitsev
2023-07-13 11:45 ` Thorsten Leemhuis
2023-07-14 20:19 ` Konstantin Ryabitsev
2023-07-15 11:30 ` Thorsten Leemhuis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8c18ee62-2647-92f1-6430-5af650f8bc11@leemhuis.info \
--to=linux@leemhuis.info \
--cc=konstantin@linuxfoundation.org \
--cc=regressions@lists.linux.dev \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).