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

[Takashi Iwai <tiwai@suse.de>]

On Sat, 08 Sep 2018 10:45:32 +0200,
Jonathan Cameron wrote:
> 
> On 7 September 2018 20:44:54 BST, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> 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.
> 
> 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.
>