Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"
From:   Slade Watkins <srw@sladewatkins.net>
In-Reply-To: <YzXK6Px+BrNuuMZH@pendragon.ideasonboard.com>
Date:   Thu, 29 Sep 2022 15:00:00 -0400
Cc:     "Artem S. Tashkinov" <aros@gmx.com>,
        Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
        Thorsten Leemhuis <linux@leemhuis.info>,
        workflows@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "regressions@lists.linux.dev" <regressions@lists.linux.dev>,
        ksummit@lists.linux.dev
Content-Transfer-Encoding: quoted-printable
Message-Id: <49D9FA95-4C73-40BA-A112-93DDFD77D1A2@sladewatkins.net>
References: <aa876027-1038-3e4a-b16a-c144f674c0b0@leemhuis.info>
 <05d149a0-e3de-8b09-ecc0-3ea73e080be3@leemhuis.info>
 <93a37d72-9a88-2eec-5125-9db3d67f5b65@gmx.com>
 <20220929130410.hxtmwmoogzkwcey7@meerkat.local>
 <7b427b41-9446-063d-3161-e43eb2e353f9@gmx.com>
 <20220929135325.4riz4ijva2vc7q5p@meerkat.local>
 <95c3384b-53d0-fd6c-6ec5-a7e03fdeddfc@gmx.com>
 <F300ED64-5E8E-4060-89DC-C98BC5FF08E6@sladewatkins.net>
 <YzXK6Px+BrNuuMZH@pendragon.ideasonboard.com>
To:     Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Precedence: bulk

Hey there,

> On Sep 29, 2022, at 12:42 PM, Laurent Pinchart =
<laurent.pinchart@ideasonboard.com> wrote:
>=20
> 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. Even for =
patches
> we need to rely on patchwork, and that's far from perfect.

Yeah, I (sort of) changed my mind on this [1], but you=E2=80=99re right: =
it lacks tracking issues from reported-to-fixed, and unless something =
was engineered specifically for it, we=E2=80=99re out of luck.

>=20
> I agree with the comment that was repeated multiple times: it's quite
> pointless to improve the tooling if we don't first improve the =
process,
> and find a way to allocate people and time to handling bug reports. =
Even
> if bugzilla has reached EOL upstream, and even if it isn't perfect, =
the
> instance runs today, and gives us a tracker that could be used to =
design
> a proper process and implement it, should we desire to do so. There's =
no
> chicken-and-egg issue to be solved where lack of tooling would prevent
> the implementation of a bug tracking process. I'm quite confident =
that,
> if we manage to implement a bug tracking process, we will find a way =
to
> get the tooling we need, be it through bugzilla or something else.

Right.=20

To be honest, I think the best move from here is improve the process =
first, then worry about everything else when the time comes. Can=E2=80=99t=
 really go any further without first addressing the process in my =
opinion. The important thing to remember is that nothing implemented =
will ever be "perfect.=E2=80=9D That=E2=80=99s just not possible. =
However, we _can_ make something that=E2=80=99ll work and continue =
refining it over time.=20

[1] =
https://lore.kernel.org/lkml/C4935ACC-65C8-4705-B9FF-A1CA0A648B9D@sladewat=
kins.net/

Cheers,
-srw