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

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Tue, Jun 27, 2017 at 08:31:17PM +0200, Takashi Iwai wrote:
> 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).

That'd be great. It sounds like we have trees like this for media, and
wireless. Not sure of others.

  Luis