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: <238f5350125e618c323f42e3885b5ff887241ae0.camel@HansenPartnership.com>
Date:   Thu, 29 Sep 2022 11:26:07 -0400
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     "Artem S. Tashkinov" <aros@....com>,
        Thorsten Leemhuis <linux@...mhuis.info>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Cc:     workflows@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        ksummit@...ts.linux.dev
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"

On Thu, 2022-09-29 at 12:22 +0000, Artem S. Tashkinov wrote:
> Let me be brutally honest here, if you're working on the kernel,
> specially for a large company such as e.g. Intel, you're _expected_
> to address the issues which are related to the kernel component[s]
> you're maintaining/developing otherwise it's not "development" it's
> "I'm dumping my code because my employer pays me to do that". That
> also means you're expected to address bug reports.
> 
> It's correct I've tried to help people with bug reports posted on
> bugzilla.kernel.org but it's a tough task considering that absolute
> most kernel developers are not signed up, thus most bug reports are
> never seen by respective developers.

The never seen/never responded to metric is rather bogus.  The sad fact
is that a lot of bug reports aren't actionable, meaning the reporter
can't give a reproducer and also can't easily test patches  sometimes
by luck the maintainers can work out what the issue is but a lot of the
time they have no idea.  Then there are ton's of bug reports with
responses like "I think xxx commit fixes your problem, can you test it"
for which the conversation dies there.  There's also the thundering
herd problem: some bugs get reported by many different people (as
different bug reports) but usually the subsystem only engages with one
to fix the issue.  In theory bugzilla can mark the latter as dups, but
that requires someone to spend an enormous amount of time on evaluation
and admin.

That's not to say we can't improve our process, it's just to set
expectations that we're never going to approach anywhere near a perfect
bug process.  Most of the improvements that worked so far involve
having someone coach bug reporters through the process of either
testing patches or reproducing the problem in a more generic
environment ... which I think most people would agree can't really fall
wholly on maintainers.

Regards,

James