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 79F74EBD for ; Wed, 5 Sep 2018 13:17:01 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E010A8 for ; Wed, 5 Sep 2018 13:17:00 +0000 (UTC) Date: Wed, 05 Sep 2018 15:16:59 +0200 Message-ID: From: Takashi Iwai To: James Bottomley In-Reply-To: <1536142432.8121.6.camel@HansenPartnership.com> References: <1536142432.8121.6.camel@HansenPartnership.com> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Distribution kernel bugzillas considered harmful List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 05 Sep 2018 12:13:52 +0200, James Bottomley wrote: > > The first suggestion is that kernel builds are pretty much automated > and we try to make every commit buildable, so could we automate the > machinery that allows a customer to do bisection simply by installing a > kernel package? (we here, obviously means the distro, but going from > git bisect to kernel package would be the useful link). Oh yeah, that's a thing I've been dreaming for years! :) A part of problems is the build power: it still takes an hour or longer (depending on arch) to build a full distro kernel package, for example, on OBS. That's too painful for bisection. So some semi-automatic way to reduce the config would be required for usable bisection. I guess automatic make localmodconfig, prep the repo and kick off. Also some garbage collections for stale repos, etc. > Second suggestion is that the bugzillas need to say much more strongly > that the reporter really needs to confirm the fix in upstream and do > the bisection themselves (and ideally request the backport to stable > themselves). OK, distros definitely need to try hard not to annoy upstream devs. In the case of SUSE Kernel, we usually ask testing the latest (more-or-less) vanilla kernel at first. If it's an upstream problem, then it's often tossed to the upstream. If it's already addressed in the upstream kernel, we take the responsibility for backports. Asking bisection by reporter is usually the last resort. It'd be helpful if we get any suggestion to improve the process. thanks, Takashi