Re: [Ksummit-discuss] [MAINTAINER SUMMIT] How can we treat staging drivers better?

[Takashi Iwai <tiwai@suse.de>]

On Fri, 07 Sep 2018 21:44:54 +0200,
Mauro Carvalho Chehab wrote:
> 
> Em Wed, 05 Sep 2018 15:35:53 +0200
> Takashi Iwai <tiwai@suse.de> 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 <mchehab@kernel.org>
> 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