Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Bug reporting feedback loop

[Takashi Iwai <tiwai@suse.de>]

On Thu, 22 Jun 2017 00:34:11 +0200,
Laura Abbott wrote:
> 
> Fedora tends to follow the most recent stable kernel very closely
> (e.g. 4.11.6 is currently pending for Fedora 24, 25, and 26).
> This works well enough, but there still seem to be some
> disconnects in the bug reporting process. Examples I can think of:
> 
> - When users report bugs on the Fedora tracker that look like
> actual upstream bugs, what's the best way to have those reported?
> I typically end up having to summarize from the Fedora bugzilla
> and send an e-mail which ends up being tedious. Can we make this
> bug reporting easier for non-kernel developers?

The topic is what I wanted to brought up, so thanks for heading up,
Laura.

Below are other related points I noticed while working on openSUSE /
SUSE kernel bugzilla triage:

- Very little information about the bug reporting:
  MAINTAINERS file lists only a few.  (Oh, my area also missing...)
  For some areas, it's extremely hard to report a bug.  There is
  always a fallback to LKML, but who reads it?

- The inconsistent bug tracking over the whole kernel areas:
  which way to report purely depends on the subsystem.  Even inside a
  subsystem, some prefer bugzilla while some don't.

- No information about debugging:
  each subsystem tends to have a dedicated script or tool to gather
  the debug information, but it remains secret like grandmother's
  recipe.

- Not well tied with regression tracking:
  for the already released kernels, we have no way to check what's
  still broken and what's been fixed.  Even a simple check list would
  be helpful...

- Inactive bug handling:
  many bug reports on bugzilla are just ignored and rotten.
  In most cases, maintainers play a role as "bug master" on bugzilla.
  But they are often too overloaded or don't pay much attention on old
  bugs.  Later on, when the bug list becomes a pile, they loose the
  gut to solve such bugs any longer.  (The model is the man standing
  on the mirror.)
  

The bug handling really need a big resource.  It takes time to
analyze, fix it, and it needs more efforts for communication, as the
bug reporter tend to have less development experiences.

It would be great to have someone assigned helping for bug  tracking
in both upstream (kernel subsystem) side, and in distributor side.
We have a better coordination regarding the security bugs, and it
should be extended for larger areas.


About your other points:
> - There's still a gap between when bugs hit Linus' tree and when
> stable releases come out. This is not a knock against stable or
> a request for stable to go faster :). I try
> and monitor stable@ for fixes but there still seems to be a
> large time gap for identifying fixes that have been fixes in
> master that are relevant to a recent stable release.

IMO, the stable upstream development is fast enough.  A fast delivery
of a particular fix can be done in the distro side, after all.


> - Are pictures of kernel panic still the most reliable method
> of getting information for early crashes? I keep getting pictures
> in 'creative' formats. 

There have been discussions about this, sending QR code, or whatever,
but I don't see any development since then, unfortunately.
But as a "reliable" method, taking the picture always works, it's not
too bad in the end.


thanks,

Takashi