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: <YzcbJsC9QfY/B8IZ@pendragon.ideasonboard.com>
Date:   Fri, 30 Sep 2022 19:36:54 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     "Bird, Tim" <Tim.Bird@...y.com>
Cc:     Thorsten Leemhuis <linux@...mhuis.info>,
        Slade Watkins <srw@...dewatkins.net>,
        "Artem S. Tashkinov" <aros@....com>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        "workflows@...r.kernel.org" <workflows@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        "ksummit@...ts.linux.dev" <ksummit@...ts.linux.dev>
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"

On Fri, Sep 30, 2022 at 04:19:56PM +0000, Bird, Tim wrote:
> > -----Original Message-----
> > From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> > 
> > Hi Thorsten,
> > 
> > On Fri, Sep 30, 2022 at 11:35:16AM +0200, Thorsten Leemhuis wrote:
> > > On 29.09.22 18:42, Laurent Pinchart wrote:
> > > > On Thu, Sep 29, 2022 at 10:54:17AM -0400, Slade Watkins wrote:
> > > >>> On Sep 29, 2022, at 10:22 AM, Artem S. Tashkinov <aros@....com> wrote:
> > > >>>
> > > >>> I've mentioned several times already that mailing lists are _even worse_
> > > >>> in terms of reporting issues. Developers get emails and simply ignore
> > > >>> them (for a multitude of reasons).
> > > >>
> > > >> It’s 100% true that emails get _buried_ as waves of them come in (LKML
> > > >> itself gets hundreds upon hundreds a day, as I’m sure all of you know)
> > > >> and it just isn’t something I personally see as viable, especially for
> > > >> issues that may or may not be high priority.
> > > >
> > > > E-mails are not that bad to report issues, but they can't provide the
> > > > core feature that any bug tracker oughts to have: tracking. There's no
> > > > way, with the tools we have at the moment (including public-inbox, b4
> > > > and lei), to track the status of bug reports and fixes.
> > >
> > > Well, I'd disagree partially with that, as my regression tracking bot
> > > "regzbot"
> > > (https://urldefense.com/v3/__https://gitlab.com/knurd42/regzbot/-
> > /blob/main/docs/getting_started.md__;!!JmoZiZGBv3RvKRSx!7f8O2QaGyWgxASwg1_bxsV53uWPINzzBa_MLMZMooa6qL6jdk8ZBVYrB_
> > mypjw0H3yv5IPdNJ2qQThzMLKbrOUQMFMO1x2V2$
> > > ; https://urldefense.com/v3/__https://linux-
> > regtracking.leemhuis.info/regzbot/mainline/__;!!JmoZiZGBv3RvKRSx!7f8O2QaGyWgxASwg1_bxsV53uWPINzzBa_MLMZMooa6qL6jdk8Z
> > BVYrB_mypjw0H3yv5IPdNJ2qQThzMLKbrOUQMFKROzSJY$  ) does
> > > exactly does that: tracking, by connect the dots (e.g. monitoring
> > > replies to a report as well recording when patches are posted or
> > > committed that link to the report using Link: tags), while making sure
> > > nothing important is forgotten. But sure, it's still very rough and
> > > definitely not a full bug-tracker (my goal is/was to not create yet
> > > another one) and needs quite a bit of hand holding from my side. And I
> > > only use it for regressions and not for bugs (on purpose).
> > 
> > Patchwork does something similar for patches, and I agree that it would
> > be possible to use e-mail to manage and track bug reports with tools on
> > top (and don't worry, I'm not asking for regzbot to be turned into a bug
> > tracker :-)). It however has to rely on lots of heuristics at the
> > moment, as the data we exchange over e-mail is free-formed and lacks
> > structure. I've been dreaming of support for structured data in e-mails,
> > but that's a pipe dream really.
> 
> E-mails sent from a web interface could have as much structure as you'd like.
> So one avenue would be to set up a nice interface for bug reporting, that just
> delivered the form data in e-mail format to the proposed bug-receiving mail list.
> 
> Also, if an e-mail receiver (something automated) gave a quick response on missing fields, I think
> you could quickly train users (even first-time bug submitters) to provide required
> data, even if they're sending from a free-form e-mail client.

In my dream, we could even teach some mail clients to do so. There's a
bit of chicken and egg issue of course, but if the form data is in a
human-writable form, it may be possible to start on the server side
first, and then address clients.

-- 
Regards,

Laurent Pinchart