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

[Jonathan Cameron <jic23@jic23.retrosnub.co.uk>]

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?

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...

>
>> 
>> - 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.