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

James Bottomley James.Bottomley at HansenPartnership.com
Wed Sep 5 16:21:37 UTC 2018


On Wed, 2018-09-05 at 15:35 +0200, Takashi Iwai wrote:
> 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.
> 
> - 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.
> 
> 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.

I think subsystems should be able to opt out of staging entirely.  For
SCSI, we want to look at the substantive command interaction issues and
(for our manifold sins) are used to reading code that makes your eyes
bleed, so polishing staging drivers with whitespace changes for months
doesn't serve us at all.

James



More information about the Ksummit-discuss mailing list