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 07E9A38DB for ; Tue, 9 Jul 2019 21:05:20 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 42DCF87C for ; Tue, 9 Jul 2019 21:05:19 +0000 (UTC) Date: Tue, 09 Jul 2019 23:05:17 +0200 Message-ID: From: Takashi Iwai To: "Rafael J. Wysocki" In-Reply-To: <2859305.DT5vN9tDxJ@kreacher> References: <20190703013557.GQ11506@sasha-vm> <20190708151040.GB1548@kroah.com> <2859305.DT5vN9tDxJ@kreacher> 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] [MAINTAINERS SUMMIT] stable kernel process automation and improvement List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 09 Jul 2019 17:44:13 +0200, Rafael J. Wysocki wrote: > > On Monday, July 8, 2019 11:31:45 PM CEST Jiri Kosina wrote: > > On Mon, 8 Jul 2019, Greg KH wrote: > > > > > Well, I think the conversation will go just like it has in the past for > > > this issue: > > > "We need to have someone track regressions!" > > > "X said they would do it but they need to be paid, any company > > > willing to sponsor this?" > > > {crickets} > > > > SUSE has actually been funding this for quite some time (back when Rafael > > was doing it), but it's really tricky. > > > > We of course realize it's very important long-term activity, from which > > everybody profits. > > > > At the same time, you need somebody who *really deeply* understands > > everything inside and around the kernel development, otherwise you get > > more harm and chaos than added value out of the whole excercise. > > > > And if you have such a person (like we had Rafael), it's unlikely that > > person would want to do that work forever, and the funding company is also > > losing brainpower in other, more development-related areas (like PM in > > Rafael's case) at the same time. > > > > So it's not as simple as "hey, you, company making money on linux, go pay > > someone to do this". > > > > If I remember correctly (Rafael for sure would remember better), there > > were some attempts to have the regression tracking made by someone much > > more juniorish, but that person got of course immediately overwhelmed. > > There were such attempts and yes, the people dropped the ball eventually. > > Honestly, I don't agree with the idea that one person can practically track > regression on the whole kernel basis today, because there is too many potential > sources of information to follow. You'd need to track all of the mailing lists used for > development, bug tracking systems in many places and so on. > > When I was tracking regressions, it was more or less sufficient to follow the LKML, > and that was hard enough already at that time, but it is not sufficient any more (and > even the LKML itself has become much more of a fire hose since then). > > The tracking of regressions, to be effective, would need to scale at least in the > same way as the development process does IMO. Agreed. And, I believe the key is to establish the standard way to report a regression from each subsystem maintainer side. That is, instead of a "regression manager" gathering the regression reports alone by him/herself, we let each maintainer reporting the regression more easily to a central place. And there we simply gather and provide the link to each regression report on a dashboard. Of course, this would need educations to each maintainer and developer, but it should be more scalable and sustainable than a top-down model. thanks, Takashi