Message-ID: <YzsDbeF8WQHy9Hat@pendragon.ideasonboard.com>
Date:   Mon, 3 Oct 2022 18:44:45 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Thorsten Leemhuis <linux@...mhuis.info>,
        Slade Watkins <srw@...dewatkins.net>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        "Artem S. Tashkinov" <aros@....com>, 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
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"

On Mon, Oct 03, 2022 at 11:26:05AM -0400, Steven Rostedt wrote:
> On Mon, 3 Oct 2022 14:59:54 +0200 Thorsten Leemhuis wrote:
> 
> > > With the band-aids you outline in place: do you think it would it be
> > > beneficial to have a liaison holding users’s hands through the
> > > process, _then_ triaging to developers by contacting them with the
> > > information they need?  
> > 
> > Well, yes and no. :-/
> > 
> > Thing is: up to a point that's something I do already (and will likely
> > continue to do at least for a while) when the reported issue is a
> > regression. But to be fair, I often could help way more if I wanted to,
> > but there are only so many hours in a day and other things to take care
> > of (regression tracking is only a part-time thing for me currently). So
> > some help there might be handy; would get load of the developers as
> > well, as they often are more willing to help users when a report is
> > about a regression.
> 
> Are you asking for help in the regression tracking?
> 
> > But for other issues (aka regular bugs) I don't think it's worth it,
> > because why only help those users that report to bugzilla (you didn't
> > say that, but it sounded to me like the focus is on it)? There are
> > people that try to use the mailing lists, but do it badly and never get
> > a reply (for example because they sent their report just to LKML). They
> > could need help, too; maybe helping them should even be priority, as
> > they at least tried to do what most kernel developers want them to do,
> > hence their reports might be better, too.
> 
> Could do both.
> 
> > But there is a more important reason why I think having a liaison might
> > not be worth it for now: It IMHO would be much better to spend the time
> > and effort on other things that enable users submitting better bug
> > reports in the first place. I have no concrete and well-thought-out
> > ideas at hand what to do exactly, but here are a few vague ones:
> > 
> >  * create an app (ideally usable locally and on the web) that guides
> > users through generating a good bug report (let's leave the way of
> > submission aside for now). That app could handle quite a few of the
> > steps that https://docs.kernel.org/admin-guide/reporting-issues.html
> > currently mentions. It for example could check if the kernel looks to be
> > vanilla, if the kernel is fresh, if the kernel is tainted, if an Oops is
> > the first one or just a follow-up error; maybe that app could even
> > decode stack-traces locally in some environments; and it could collect
> > and upload logs as well. It could also explain certain things to users
> > when not fulfilled, for example why it's not worth to report a problem
> > that happens with an old kernel.
> 
> Christoph mentioned Debian's reportbug utility. That does a pretty good
> job at walking people through how to report a bug. It could also get
> information about the current environment that would be useful too. Perhaps
> something like that?
> 
> >    Sure, these apps never work perfect and doing it right is a lot of
> > work, but I guess one could make things a lot easier for many users
> > especially for our case. I assume other projects have done something
> > like that so that we could learn from them.
> > 
> >  * Improve https://docs.kernel.org/admin-guide/reporting-issues.html
> > further. I have some ideas there, but other things are higher on my
> > priority list currently. That document in the end somehow needs to
> > become less scary looking while still providing all important details
> > for situations where a reporter might need them.
> > 
> >  * Write new docs relevant for bug reporting. We for example still have
> > no well written and simple to understand text that explains bisection to
> > people that are new to git, bisection, or compiling kernels in general.
> > Speaking of which: we iirc are also missing a text that properly
> > explains how to quickly configure and compile a kernel using "make
> > localmodconfig" (I mean something like
> > http://www.h-online.com/open/features/Good-and-quick-kernel-configuration-creation-1403046.html)
> 
> The sad part is that most people that are going to report a bug is not
> going to read a full document to figure out how to do it. Usually when
> someone hits a bug, they are doing something else. And it's a burden to
> report it. Obviously, they want it to be fixed, but it's viewed as a favor
> to the developer and not the user to get it fixed, as it's likely seen as a
> mistake by the developer that the bug exists in the first place.

It really depends on how badly the bug affects the reporter. I'm sure
that a bug that prevents GPU or audio from working alone on a shiny
brand new laptop will see lots of pings. A side issue noticed by the
user that wouldn't really affect them is more likely to end up in a
blackhole. I recently faced issues with a display controller. I sent
patches for the problems affecting my use case, and only notified the
maintainer for the other issues. Those have been "added to their todo
list (TM)". But is that really a problem ? If I'm not affected and
neither is the maintainer, there's likely better use of their time, at
least until a user who is really affected by the problem shows up.

> Having a tool like reportbug that walks you through the steps of reporting
> it would be the best way to do so. As the reporter doesn't need to think
> too hard and just answer questions and let the tool do all the work.
> 
> >  * Not sure, maybe a list of things that known to be broken might be
> > good to have? Like "yes, we know that nouveau is slow, but we can't do
> > anything about this" or "driver 'wifi-foo' only supports a small subset
> > of the features the hardware offers, so don't report bugs if bar, baz
> > and foobar don't work".
> 
> The tool could possibly reply with known issues, and state something like
> "We are aware of this issue, and are currently trying to figure it out."

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists