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

[Slade Watkins <srw@sladewatkins.net>]

Hey there,

> On Sep 29, 2022, at 12:42 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> 
> 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’re right: it lacks tracking issues from reported-to-fixed, and unless something was engineered specifically for it, we’re out of luck.

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

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’t 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.” That’s just not possible. However, we _can_ make something that’ll work and continue refining it over time. 

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

Cheers,
-srw