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

[Takashi Iwai <tiwai@suse.de>]

On Tue, 27 Jun 2017 19:53:21 +0200,
Luis R. Rodriguez wrote:
> 
> On Thu, Jun 22, 2017 at 02:36:13PM +0200, Jiri Kosina wrote:
> > On Wed, 21 Jun 2017, 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?
> > 
> > Just as a data point -- we do a "Kernel of the day" build of a branch that 
> > follows Linus' tree (with a few SUSE specific patches floating on top of 
> > it) and provide it in an optional package repository.
> > 
> > That allows the reporter to easily check whether the issue has been fixed 
> > in latest upstream without needing to have the skills required to compile 
> > own kernel.
> > 
> > If the issue is confirmed to be present in latest upstream as well, our 
> > internal person / maintainer responsible for that particular area usually 
> > takes over (there are cases when the reporter prefers to report the bug 
> > upstream by himself though).
> > 
> > I am not sure if there is a way how to improve this process even further 
> > ... do you have any particular ideas?
> 
> The Kernel Of The Day (KOTD) helps *a lot*. On the XFS front I can say that 90%
> of the time so far most bugs can simply be reverse bisected by testing an issue
> with KOTD and if it works then doing a reverse bisect. So much so that I
> actually *yearn* for the day we get an actual real valid upstream bug. The
> other 10% BTW consist of "bad backports" so far.
> 
> But one day it comes that KOTD is not sufficient, and there is that pesky delta
> on linux-next which *might* also have a fix for you. Problem is booting
> linux-next can often fail. Based on personal experience with testing linux-next
> more regularly on more machines over the years I can say we are getting much
> better with this these days, but every now and then its just poop. That said,
> we have a not-so-well known daily linux-next KOTD rpm type of tree as well.
> So I recommend that as a next step.
> 
> Due to the possible failures possible with linux-next, or random regressions
> with other subsystems you often only want to test *one* subsystem. To help
> with this there are two options I'm aware of:
> 
>   o Subsystem maintiners also backport their -next tree for vanilla, in the
>     the like of wireless-testing, which only carries 802.11 on Linus' tree.
>     Not sure if other subsystems have similar type of trees, if not I encourage
>     it.
> 
>   o Backports: backporting to random kernels can be a pain in the ass, but
>     backporting to the KOTD should not take much effort if you have the
>     right framework [0]. For instance I just created an XFS backport from
>     linux-next to KOTD in one day's effort, I can use this to generate
>     a tarball for modules for folks to try on top of KOTD. If this would 
>     actually be maintained upstream then the amount of work needed is even less,
>     and you can have daily snapshots generated. Although sometimes backports
>     can be buggy, to my surprise using Coccinelle actually has improved
>     correctness of backports, this is only visible once you replace a series
>     of patches with the output form an SmPL grammar patch. Given Coccinelle
>     is also used, once you backport one subsystem driver, adding more is
>     drivers from the same subsystem becomes relatively easier.

I guess it shouldn't be too difficult to build a kernel package based
on subsystem for-next branch regularly like we do for KOTD and
linux-next kernel packages.  You'd need to set up some cron job to git
pull, repackage tarball and adjust config file somehow automatically,
then feed it to osc (in the case of openSUSE/SUSE OBS).


thanks,

Takashi