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 04DC21133 for ; Mon, 10 Sep 2018 18:49:59 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F1DEC102 for ; Mon, 10 Sep 2018 18:49:57 +0000 (UTC) Date: Mon, 10 Sep 2018 20:49:54 +0200 Message-ID: From: Takashi Iwai To: Jonathan Cameron In-Reply-To: <6B686C53-9671-43D3-B697-F341D15C05B5@jic23.retrosnub.co.uk> References: <20180907164454.3713a8be@coco.lan> <6B686C53-9671-43D3-B697-F341D15C05B5@jic23.retrosnub.co.uk> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Mauro Carvalho Chehab , ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] How can we treat staging drivers better? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, 08 Sep 2018 10:45:32 +0200, Jonathan Cameron wrote: > > On 7 September 2018 20:44:54 BST, Mauro Carvalho Chehab wrote: > >Em Wed, 05 Sep 2018 15:35:53 +0200 > >Takashi Iwai escreveu: > > > >> The staging driver is a wonderful process to promote the downstream > >> code to the upstream, but I have doubt whether it's working really as > >> expected for now. > >> > >> - Often the drivers live forever in staging although they should have > >> been moved to the upper, properly maintained, subsystems. > >> > >> - Code changes in staging are mostly only scratching surfaces, minor > >> code style cleanups, etc, what checkpatch suggests. > >> > >> - There are little communications with the corresponding subsystem; > >> already a few times I was surprised by casually finding a staging > >> driver code by grepping for preparing API changes. > > > >What we do in the case of media drivers is that we have a > > drivers/staging/media > >directory with a proper MAINTAINERS' entry: > > > >MEDIA INPUT INFRASTRUCTURE (V4L/DVB) > >M: Mauro Carvalho Chehab > >P: LinuxTV.org Project > >L: linux-media@vger.kernel.org > >W: https://linuxtv.org > >Q: http://patchwork.kernel.org/project/linux-media/list/ > >T: git git://linuxtv.org/media_tree.git > >S: Maintained > >F: Documentation/devicetree/bindings/media/ > >F: Documentation/media/ > >F: drivers/media/ > >F: drivers/staging/media/ > >... > > > >This way, we receive notifications (both on my e-mail and at the media > >ML) about changes there. > > > >I also asked Greg to avoid picking patches directly to it. So, > >we're able to manage what's there. > > Likewise, IIO staging driver patches are handled on the same mailing list as non staging ones. > > Partly that is historical given IIO itself graduated from staging but it works really well. > If people aren't interested they can just not join in with those threads. > > Perhaps this model would help more generally? I think this would work for many subsystems, yes. Some would like to avoid that, but we can let each maintainer choose, of course. > A really good use we make of the drivers in staging is to mentor new contributors through > cleaning them up. We normally only drop drivers if no one has hardware and it is not easy to get. > This is not typically trivial clean up but more major rework. > > Often hardware companies are happy to lend or give dev boards to enable this. This includes > drivers that set there unloved for lots of years... Agreed, it can be a good way to promote the downstream works, and at the same time, it's a good educational place. thanks, Takashi > >> - Then some drivers are pushed back after long time stay in staging > >> (lustre is the recent remarkable case); > >> it's understandable, but is definitely no happy end in both sides, > >> after all. > > > >We had a recent case: the (really big) atomisp driver. > > > >It is not good to apply a driver and remove it some Kernel versions > >later without actually merging it at the "real" mainstream , but > >I guess this is unavoidable, if we want to have a staging area. > > > >In the case of media, we've been succeeded on promoting drivers > >from staging, and to use staging as a step before drivers removal. > > > >But yeah, I feel the pain: sometimes stuff gets "stucked" there > >for a long time without any significant changes, as it is easy > >to forget what's under the staging carpet. > > > >Not sure what's the best way to solve it. Perhaps we could have a > >"soft" policy of removing drivers from staging after a certain number > >of > >Kernel releases, and some robot monitoring it, dropping e-mails to > >both subsystem maintainers and patch authors when a driver takes > >longer than that. The maintainer could then check if the patches > >submitted along that time were in the direction of removing it > >from staging and if it would be worth to give more time to the > >developer to fix, or otherwise if all he says is just whitespace > >and checkpatch cleanup to just ditch it. > > > >> > >> So, I'd like to hear how we can improve the staging driver situation, > >> a better communication with staging driver people and the subsystem / > >> core devs. > >> > >> > >> thanks, > >> > >> Takashi > >> _______________________________________________ > >> Ksummit-discuss mailing list > >> Ksummit-discuss@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > > > > > > > >Thanks, > >Mauro > >_______________________________________________ > >Ksummit-discuss mailing list > >Ksummit-discuss@lists.linuxfoundation.org > >https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >