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 000E75A9 for ; Thu, 22 Jun 2017 14:08:15 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3BCFF1F2 for ; Thu, 22 Jun 2017 14:08:15 +0000 (UTC) Date: Thu, 22 Jun 2017 16:08:13 +0200 Message-ID: From: Takashi Iwai To: Laura Abbott In-Reply-To: <1de3c642-a4b7-1065-5c35-ba32866d471d@redhat.com> References: <1de3c642-a4b7-1065-5c35-ba32866d471d@redhat.com> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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 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