From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 13C1ACA2 for ; Tue, 27 Jun 2017 19:04:27 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44C8ECC for ; Tue, 27 Jun 2017 19:04:26 +0000 (UTC) Date: Tue, 27 Jun 2017 21:04:24 +0200 From: "Luis R. Rodriguez" To: Takashi Iwai Message-ID: <20170627190424.GW21846@wotan.suse.de> References: <1de3c642-a4b7-1065-5c35-ba32866d471d@redhat.com> <20170627175321.GS21846@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Bug reporting feedback loop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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