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 BCA541124 for ; Mon, 10 Sep 2018 18:52:32 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 41A1E102 for ; Mon, 10 Sep 2018 18:52:32 +0000 (UTC) Date: Mon, 10 Sep 2018 20:52:30 +0200 Message-ID: From: Takashi Iwai To: Mauro Carvalho Chehab In-Reply-To: <20180907164454.3713a8be@coco.lan> References: <20180907164454.3713a8be@coco.lan> 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] How can we treat staging drivers better? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 07 Sep 2018 21:44:54 +0200, 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. Good to hear, I believe we should follow the same for the sound stuff. > > - 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. What was the reason of drawback, BTW? I think it'd be helpful if we can gather more data, e.g. good examples to show how it can succeed, as well as anti-patterns to learn what makes things failing. thanks, Takashi