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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thu, Sep 29, 2022 at 10:54:17AM -0400, Slade Watkins wrote:
> Hey!
> 
> Jumping in here to offer my input...
> 
> > On Sep 29, 2022, at 10:22 AM, Artem S. Tashkinov <aros@gmx.com> wrote:
> > 
> > That leaves us with Bugzilla that no one wants to touch and some people
> > actively want to delete altogether. In other words, no central place to
> > report bugs or keep track of them.
> 
> This is the current problem that seems to be appearing here. I get why
> no one wants to touch it, but it doesn’t solve the problem. 
> 
> As you said:
> 
> > 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. Even for patches
we need to rely on patchwork, and that's far from perfect.

When things fall through the cracks (and at the moment it's more of a
sieve with very large holes, if not a bottom-less pot), we mostly assume
that, if the problem is important enough, the submitter will ping time
after time until a fix is produced and merged. There is no way to
produce a list of open issues.

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.

> > Getting back to my first message in this discussion,
> > 
> > * Let's refresh all the components in Bugzilla
> > * Components may not have any people responsible for them at all. Bug
> > reporters will have to CC the people they are interested in.
> > * Let's subscribe the past six months of developers (using git commit logs)
> > * Whoever wants to unsubscribe is free to do so.
> 
> Not a terrible idea to me, though obviously, that’s up for debate.
> 
> > If not for bugzilla, let's use something more modern. I don't know any
> > comparable projects however. Trac is truly horrible. You cannot even
> > unsubscribe from bug reports. Maybe I've missed something. Discourse?
> > Not a bug tracker per se but can certainly work this way.
> 
> Discourse probably isn’t the best fit here, in my opinion. Jira and
> YouTrack are the only ones I personally know of that are similar to
> Bugzilla, although as far as I know, they aren’t open source...

-- 
Regards,

Laurent Pinchart