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

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

[Takashi Iwai]

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.


thanks,

Takashi

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

[Dan Carpenter]

On Wed, Sep 05, 2018 at 03:35:53PM +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.

The only one that comes to mind is comedi.  I think those guys know that
everyone is fine with them moving the code.

Do you have another example?

> 
> - Code changes in staging are mostly only scratching surfaces, minor
>   code style cleanups, etc, what checkpatch suggests.

That's probably true for the wireless drivers because converting them
to use mac80211 is complicated.  The other drivers seem to be doing
better.

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

Which ones are you interested in?  I'd always prefer to hand off staging
drivers to an existing subsystem but it's not always clear who that
should be.

regards,
dan carpenter

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

[Takashi Iwai]

On Wed, 05 Sep 2018 15:55:28 +0200,
Dan Carpenter wrote:
> 
> On Wed, Sep 05, 2018 at 03:35:53PM +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.
> 
> The only one that comes to mind is comedi.  I think those guys know that
> everyone is fine with them moving the code.
> 
> Do you have another example?

Well, not forever, but many codes remain there for many cycles, I
thought.  But I haven't counted and no statistics, so it might be my
false impression.

> > - Code changes in staging are mostly only scratching surfaces, minor
> >   code style cleanups, etc, what checkpatch suggests.
> 
> That's probably true for the wireless drivers because converting them
> to use mac80211 is complicated.  The other drivers seem to be doing
> better.

So which drivers were the good examples?  Maybe we can learn from
them.

> > - 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.
> 
> Which ones are you interested in?

My primary interest is the sound stuff.

> I'd always prefer to hand off staging
> drivers to an existing subsystem but it's not always clear who that
> should be.

IMO, *that* is the problem -- no proper taker in the subsystem.


thanks,

Takashi

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

[Sean Paul]

On Wed, Sep 5, 2018 at 9:56 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> On Wed, Sep 05, 2018 at 03:35:53PM +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.
>
> The only one that comes to mind is comedi.  I think those guys know that
> everyone is fine with them moving the code.
>
> Do you have another example?
>

The android stuff has been in a constant state of almost graduating
for a while now.

> >
> > - Code changes in staging are mostly only scratching surfaces, minor
> >   code style cleanups, etc, what checkpatch suggests.
>
> That's probably true for the wireless drivers because converting them
> to use mac80211 is complicated.  The other drivers seem to be doing
> better.
>

We have the same problem in drm. There have been a few subsystem
refactors that have missed updating drivers in staging. It's also
trickier to coordinate refactors across drm/staging trees. As such, we
have been trying to dissuade people from using staging for drm.

> >
> > - 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.
>
> Which ones are you interested in?  I'd always prefer to hand off staging
> drivers to an existing subsystem but it's not always clear who that
> should be.

In the case of vboxvideo, we won't accept it in drm since it's not an
atomic driver. staging's bar for entry was lower, so the driver was
stuck in there. Perhaps we would have been better to take it in drm
behind a config, but that's not ideal either.

Sean

>
> regards,
> dan carpenter
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Greg KH]

On Wed, Sep 05, 2018 at 04:03:50PM +0200, Takashi Iwai wrote:
> On Wed, 05 Sep 2018 15:55:28 +0200,
> Dan Carpenter wrote:
> > 
> > On Wed, Sep 05, 2018 at 03:35:53PM +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.
> > 
> > The only one that comes to mind is comedi.  I think those guys know that
> > everyone is fine with them moving the code.
> > 
> > Do you have another example?
> 
> Well, not forever, but many codes remain there for many cycles, I
> thought.  But I haven't counted and no statistics, so it might be my
> false impression.

I do drop things every few kernel releases.  Sometimes people do not
notice.  I need to do a sweep and see what I can delete again, I'll try
to do that later this release cycle.

And yes, comedi does need to move out, as does a few other (speakup is
one example).  I always take patches to do this, as my cycles are less
these days due to the security crap this year :(

Also, some subsystems have moved out, on their own, to the real part of
the kernel.  Look at the -rc1 merge requests for those examples, I think
we have had that happen every kernel release for the past year or so.

> > > - Code changes in staging are mostly only scratching surfaces, minor
> > >   code style cleanups, etc, what checkpatch suggests.
> > 
> > That's probably true for the wireless drivers because converting them
> > to use mac80211 is complicated.  The other drivers seem to be doing
> > better.
> 
> So which drivers were the good examples?  Maybe we can learn from
> them.

Look at what moved out this, and the past, kernel releases for examples
(I can't remember the names at the moment, sorry).  Another driver just
got moved last week into the networking tree, so that's another success
story.

Again, it happens all the time, I don't think people are paying
attention because it's for hardware they don't care about :)

> > > - 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.
> > 
> > Which ones are you interested in?
> 
> My primary interest is the sound stuff.

Do we have sound drivers in staging other than the most and bcm2835
driver?  That's all I notice and both of those drivers have active
maintainers/developers who are working to get the code cleaned up and
pushed to the "real" part of the kernel.  most has stalled a bit these
past few months, but the developers are active and trying.  They can
always use the help.

> > I'd always prefer to hand off staging
> > drivers to an existing subsystem but it's not always clear who that
> > should be.
> 
> IMO, *that* is the problem -- no proper taker in the subsystem.

I don't understand what you mean here.  I always push code to the
subsystem-specific maintainers when they are to "graduate", I never
merge things behind maintainers backs.  If subsystems don't have
maintainers, well, I have to use my own judgement and then the
developers become the subsystem maintainers on their own.

So what do you mean by "no proper taker"?

thanks,

greg k-h

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

[Greg KH]

On Wed, Sep 05, 2018 at 10:08:00AM -0400, Sean Paul wrote:
> > Which ones are you interested in?  I'd always prefer to hand off staging
> > drivers to an existing subsystem but it's not always clear who that
> > should be.
> 
> In the case of vboxvideo, we won't accept it in drm since it's not an
> atomic driver. staging's bar for entry was lower, so the driver was
> stuck in there. Perhaps we would have been better to take it in drm
> behind a config, but that's not ideal either.

for vboxvideo, I am pretty sure I got an "it's ok to put it there" from
the DRM maintainers before I accepted it.  So they know it is there :)

If it's not ever going to be merged, maybe we should just drop it?

thanks,

greg k-h

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

[Sean Paul]

On Wed, Sep 5, 2018 at 10:23 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Sep 05, 2018 at 10:08:00AM -0400, Sean Paul wrote:
> > > Which ones are you interested in?  I'd always prefer to hand off staging
> > > drivers to an existing subsystem but it's not always clear who that
> > > should be.
> >
> > In the case of vboxvideo, we won't accept it in drm since it's not an
> > atomic driver. staging's bar for entry was lower, so the driver was
> > stuck in there. Perhaps we would have been better to take it in drm
> > behind a config, but that's not ideal either.
>
> for vboxvideo, I am pretty sure I got an "it's ok to put it there" from
> the DRM maintainers before I accepted it.  So they know it is there :)
>

Oh for sure, I didn't mean to imply it was there without our knowledge
(reading my mail back the implication is definitely there, apologies).
I think the narrative was "ack to put it there, but it'll cause pain".
If the atomic conversion was done expediently, it wouldn't be so bad,
but it's starting to become an anchor (IMO).

> If it's not ever going to be merged, maybe we should just drop it?

Yeah, I'm fine with that. It doesn't seem like anyone is super
motivated to do the atomic conversion any time soon.

Generally speaking, I think the vboxvideo experiment has shown that
staging isn't a good fit for us. For subsystems with less churn or
surrounding infrastructure, it's probably much less of an issue.

Sean

>
> thanks,
>
> greg k-h

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

[Takashi Iwai]

On Wed, 05 Sep 2018 16:20:46 +0200,
Greg KH wrote:
> 
> On Wed, Sep 05, 2018 at 04:03:50PM +0200, Takashi Iwai wrote:
> > On Wed, 05 Sep 2018 15:55:28 +0200,
> > Dan Carpenter wrote:
> > > 
> > > On Wed, Sep 05, 2018 at 03:35:53PM +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.
> > > 
> > > The only one that comes to mind is comedi.  I think those guys know that
> > > everyone is fine with them moving the code.
> > > 
> > > Do you have another example?
> > 
> > Well, not forever, but many codes remain there for many cycles, I
> > thought.  But I haven't counted and no statistics, so it might be my
> > false impression.
> 
> I do drop things every few kernel releases.  Sometimes people do not
> notice.  I need to do a sweep and see what I can delete again, I'll try
> to do that later this release cycle.
> 
> And yes, comedi does need to move out, as does a few other (speakup is
> one example).  I always take patches to do this, as my cycles are less
> these days due to the security crap this year :(
> 
> Also, some subsystems have moved out, on their own, to the real part of
> the kernel.  Look at the -rc1 merge requests for those examples, I think
> we have had that happen every kernel release for the past year or so.

OK, so it can be my false impression that things are sticking too
long.


> > > > - Code changes in staging are mostly only scratching surfaces, minor
> > > >   code style cleanups, etc, what checkpatch suggests.
> > > 
> > > That's probably true for the wireless drivers because converting them
> > > to use mac80211 is complicated.  The other drivers seem to be doing
> > > better.
> > 
> > So which drivers were the good examples?  Maybe we can learn from
> > them.
> 
> Look at what moved out this, and the past, kernel releases for examples
> (I can't remember the names at the moment, sorry).  Another driver just
> got moved last week into the networking tree, so that's another success
> story.
> 
> Again, it happens all the time, I don't think people are paying
> attention because it's for hardware they don't care about :)
> 
> > > > - 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.
> > > 
> > > Which ones are you interested in?
> > 
> > My primary interest is the sound stuff.
> 
> Do we have sound drivers in staging other than the most and bcm2835
> driver?

Yeah, that's an example I stumbled on in this week, so I raised the
topic :)

> That's all I notice and both of those drivers have active
> maintainers/developers who are working to get the code cleaned up and
> pushed to the "real" part of the kernel.  most has stalled a bit these
> past few months, but the developers are active and trying.  They can
> always use the help.

I don't blame you guys and developers, but still I think it would have
been great if the existence of the driver code was informed
beforehand.

> > > I'd always prefer to hand off staging
> > > drivers to an existing subsystem but it's not always clear who that
> > > should be.
> > 
> > IMO, *that* is the problem -- no proper taker in the subsystem.
> 
> I don't understand what you mean here.  I always push code to the
> subsystem-specific maintainers when they are to "graduate", I never
> merge things behind maintainers backs.  If subsystems don't have
> maintainers, well, I have to use my own judgement and then the
> developers become the subsystem maintainers on their own.
> 
> So what do you mean by "no proper taker"?

Well, it's what Dan mentioned -- "not always clear who to hand off".

If the staging driver is worked out from both the driver devs and the
subsystem devs, that's fine.  But, again, I believe this would have
been great if this stuff is informed and discussed together.

The cleanup and polishing the driver code is easy.  The hardest part
is the major surgery of the driver code structure and the proper API
usages.  This needs the help from the subsystem people, and it's
easier if the coordination is taken earlier, IMO.


thanks,

Takashi

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

[Andrew Lunn]

> Look at what moved out this, and the past, kernel releases for examples
> (I can't remember the names at the moment, sorry).  Another driver just
> got moved last week into the networking tree, so that's another success
> story.

I tend to look at all new network drivers, and i was involved in that
one.

In general, there is no interaction between people working on network
drivers in staging and netdev. So i have no idea what network drivers
are currently in staging. There are no requests to review them to help
get them up to mainline quality. Generally, the first time netdev
hears of them is when somebody submits a patch moving the driver. And
often that patch is created with git format-patch -M, so all we see
are renames, not the actual code. That makes it impossible to actual
review the patch.

So i think it would be useful to add some hints to the documentation
about how to get out of staging. When to get the target subsystem
involved, how to ask for reviews, how to submit it to the target
subsystem, etc.

	Andrew

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

[Joe Perches]

On Wed, 2018-09-05 at 16:20 +0200, Greg KH wrote:
> I always push code to the
> subsystem-specific maintainers when they are to "graduate", I never
> merge things behind maintainers backs.

Recently, there was an attempt to move code from 'staging'
to a more mainline tree that needed to be reviewed by the
nominal subsystem maintainer.

https://www.spinics.net/lists/netdev/msg520443.html

I believe the nominal maintainer(s) should be involved
somewhat earlier than that.

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

[Shuah Khan]

On Wed, Sep 5, 2018 at 8:41 AM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Wed, 05 Sep 2018 16:20:46 +0200,
> Greg KH wrote:
> >
> > On Wed, Sep 05, 2018 at 04:03:50PM +0200, Takashi Iwai wrote:
> > > On Wed, 05 Sep 2018 15:55:28 +0200,
> > > Dan Carpenter wrote:
> > > >
> > > > On Wed, Sep 05, 2018 at 03:35:53PM +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.
> > > >
> > > > The only one that comes to mind is comedi.  I think those guys know that
> > > > everyone is fine with them moving the code.
> > > >
> > > > Do you have another example?
> > >
> > > Well, not forever, but many codes remain there for many cycles, I
> > > thought.  But I haven't counted and no statistics, so it might be my
> > > false impression.
> >
> > I do drop things every few kernel releases.  Sometimes people do not
> > notice.  I need to do a sweep and see what I can delete again, I'll try
> > to do that later this release cycle.
> >
> > And yes, comedi does need to move out, as does a few other (speakup is
> > one example).  I always take patches to do this, as my cycles are less
> > these days due to the security crap this year :(
> >
> > Also, some subsystems have moved out, on their own, to the real part of
> > the kernel.  Look at the -rc1 merge requests for those examples, I think
> > we have had that happen every kernel release for the past year or so.
>
> OK, so it can be my false impression that things are sticking too
> long.
>
>
> > > > > - Code changes in staging are mostly only scratching surfaces, minor
> > > > >   code style cleanups, etc, what checkpatch suggests.
> > > >
> > > > That's probably true for the wireless drivers because converting them
> > > > to use mac80211 is complicated.  The other drivers seem to be doing
> > > > better.
> > >
> > > So which drivers were the good examples?  Maybe we can learn from
> > > them.
> >
> > Look at what moved out this, and the past, kernel releases for examples
> > (I can't remember the names at the moment, sorry).  Another driver just
> > got moved last week into the networking tree, so that's another success
> > story.
> >
> > Again, it happens all the time, I don't think people are paying
> > attention because it's for hardware they don't care about :)
> >
> > > > > - 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.
> > > >
> > > > Which ones are you interested in?
> > >
> > > My primary interest is the sound stuff.
> >
> > Do we have sound drivers in staging other than the most and bcm2835
> > driver?
>
> Yeah, that's an example I stumbled on in this week, so I raised the
> topic :)
>
> > That's all I notice and both of those drivers have active
> > maintainers/developers who are working to get the code cleaned up and
> > pushed to the "real" part of the kernel.  most has stalled a bit these
> > past few months, but the developers are active and trying.  They can
> > always use the help.
>
> I don't blame you guys and developers, but still I think it would have
> been great if the existence of the driver code was informed
> beforehand.
>
> > > > I'd always prefer to hand off staging
> > > > drivers to an existing subsystem but it's not always clear who that
> > > > should be.
> > >
> > > IMO, *that* is the problem -- no proper taker in the subsystem.
> >
> > I don't understand what you mean here.  I always push code to the
> > subsystem-specific maintainers when they are to "graduate", I never
> > merge things behind maintainers backs.  If subsystems don't have
> > maintainers, well, I have to use my own judgement and then the
> > developers become the subsystem maintainers on their own.
> >
> > So what do you mean by "no proper taker"?
>
> Well, it's what Dan mentioned -- "not always clear who to hand off".
>
> If the staging driver is worked out from both the driver devs and the
> subsystem devs, that's fine.  But, again, I believe this would have
> been great if this stuff is informed and discussed together.
>
> The cleanup and polishing the driver code is easy.  The hardest part
> is the major surgery of the driver code structure and the proper API
> usages.  This needs the help from the subsystem people, and it's
> easier if the coordination is taken earlier, IMO.
>

Looking at the MAINTAINERS file for staging entries, it appears some
staging drivers
are missing sub-system mailing list. Foe example this one:

FBTFT Framebuffer drivers
M:      Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
S:      Maintained
F:      drivers/staging/fbtft/

No L: for this driver

I found a few others.

Maybe the first step is to add sub-system and/or linux-kernel@vger.kernel.org
At least sub-system maintainers will be aware of the drivers when
minor cleanups happen.

thanks,
-- Shuah

> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Daniel Vetter]

On Wed, Sep 5, 2018 at 4:29 PM, Sean Paul <seanpaul@chromium.org> wrote:
> On Wed, Sep 5, 2018 at 10:23 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>>
>> On Wed, Sep 05, 2018 at 10:08:00AM -0400, Sean Paul wrote:
>> > > Which ones are you interested in?  I'd always prefer to hand off staging
>> > > drivers to an existing subsystem but it's not always clear who that
>> > > should be.
>> >
>> > In the case of vboxvideo, we won't accept it in drm since it's not an
>> > atomic driver. staging's bar for entry was lower, so the driver was
>> > stuck in there. Perhaps we would have been better to take it in drm
>> > behind a config, but that's not ideal either.
>>
>> for vboxvideo, I am pretty sure I got an "it's ok to put it there" from
>> the DRM maintainers before I accepted it.  So they know it is there :)
>>
>
> Oh for sure, I didn't mean to imply it was there without our knowledge
> (reading my mail back the implication is definitely there, apologies).
> I think the narrative was "ack to put it there, but it'll cause pain".
> If the atomic conversion was done expediently, it wouldn't be so bad,
> but it's starting to become an anchor (IMO).

Yeah I acked it for -staging. I have regrets now, but next time around
I'm probably as gullible as ever.

>> If it's not ever going to be merged, maybe we should just drop it?
>
> Yeah, I'm fine with that. It doesn't seem like anyone is super
> motivated to do the atomic conversion any time soon.
>
> Generally speaking, I think the vboxvideo experiment has shown that
> staging isn't a good fit for us. For subsystems with less churn or
> surrounding infrastructure, it's probably much less of an issue.

It slowed down a bit, but past 3 years we've merged like 2-3 new
atomic drivers per release. Now we mostly have a driver for each kind
of display IP out there, so a lot more boils down to adding support
for different variants of the same hw. So it's clearly possible to
land a simple drm atomic modeset driver without too onerous amounts of
work. vboxvideo otoh seems to not really move - looking at git log all
the changes are just general refactorings, no one seems to do the one
and only thing (cut it over to atomic, probably best as a
drm_simple_display_pipe driver) that we want. And it's now a full year
in-tree.

So all the pain (we have to refactor yet another driver using outdated
helpers/api), no gain (doesn't seem to pull in more contributors or
more bug reporters afaict) for the subsystem. Ack on removing it.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[James Bottomley]

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

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

[Daniel Vetter]

On Wed, Sep 5, 2018 at 6:21 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> 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.

>From drm's pov I second this. I have no problem with looking at very
un-kernel coding style from new drivers, if that allows us to
course-correct them on the fundamental issues right away. Polishing
can happen onces the fundamentals are sound. Before that it's just
busy work imo. Which I think is ok, it makes for great starter tasks,
but we already try to collect more relevant cleanup tasks for drm
under Documentation/gpu/todo.rst. Heck I'm totally fine merging a
driver that violates half of the checkpatch.pl bikesheds directly into
drm, as long as it's up-to-date with latest drm helpers and concepts.
Gives us good fodder for newbies and interns :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Mauro Carvalho Chehab]

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.

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

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

[Jonathan Cameron]

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.

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

[Takashi Iwai]

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

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

[Takashi Iwai]

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

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

[Laurent Pinchart]

On Monday, 10 September 2018 21:52:30 EEST Takashi Iwai wrote:
> 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 <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?

Intel pushed a huge code drop that clearly required a staging period, and then 
simply left it bitrot. No developer was committed to perform the work needed 
to de-stage the driver. I don't know whether priorities had changed internally 
or if there were no resources from day 1, but in the end it's pretty clear 
that if we had known beforehand of the outcome, the driver would likely not 
have been even a staging candidate.

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

Anti-pattern number one: push a large driver to staging knowing that you won't 
work on it anymore, and expect the community to do your work for free.

I would have expected a company like Intel to know better. Or, rather sadly, I 
probably have given up on such expectations already :-S

-- 
Regards,

Laurent Pinchart

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

[Tim.Bird]

> -----Original Message-----
> From: Laurent Pinchart
> 
> On Monday, 10 September 2018 21:52:30 EEST Takashi Iwai wrote:
> > 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.
> > >
...
> > > > - 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?
> 
> Intel pushed a huge code drop that clearly required a staging period, and
> then
> simply left it bitrot. No developer was committed to perform the work
> needed
> to de-stage the driver. I don't know whether priorities had changed internally
> or if there were no resources from day 1, but in the end it's pretty clear
> that if we had known beforehand of the outcome, the driver would likely not
> have been even a staging candidate.
> 
> > 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.
> 
> Anti-pattern number one: push a large driver to staging knowing that you
> won't
> work on it anymore, and expect the community to do your work for free.
> 
> I would have expected a company like Intel to know better. Or, rather sadly, I
> probably have given up on such expectations already :-S

I thought staging was where work was done on drivers that were submitted
to Greg's Free Linux Driver project (https://lkml.org/lkml/2007/1/29/345)
(among other things). 

Is that project still active?  Do things still move through staging as originally
intended?  Am I conflating two different things?

I'm not sure if Intel's driver qualifies as a Free Linux Driver project or not.
I can think of other companies, less experienced with kernel work than Intel,
that might still benefit from the Free Linux Driver project, and staging.

I thought the whole idea of staging was that something was better than nothing,
and that cruddy code could be taken even if the hardware vendor didn't have
the skills or inclination to do proper mainlining.
 -- Tim

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

[Laurent Pinchart]

Hi Tim,

On Monday, 10 September 2018 22:22:05 EEST Tim.Bird@sony.com wrote:
> > On Monday, 10 September 2018 21:52:30 EEST Takashi Iwai wrote:
> >> 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.
> 
> ...
> 
> >>>> - 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?
> > 
> > Intel pushed a huge code drop that clearly required a staging period, and
> > then simply left it bitrot. No developer was committed to perform the work
> > needed to de-stage the driver. I don't know whether priorities had changed
> > internally or if there were no resources from day 1, but in the end it's
> > pretty clear that if we had known beforehand of the outcome, the driver
> > would likely not have been even a staging candidate.
> > 
> >> 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.
> > 
> > Anti-pattern number one: push a large driver to staging knowing that you
> > won't work on it anymore, and expect the community to do your work for
> > free.
> > 
> > I would have expected a company like Intel to know better. Or, rather
> > sadly, I probably have given up on such expectations already :-S
> 
> I thought staging was where work was done on drivers that were submitted
> to Greg's Free Linux Driver project (https://lkml.org/lkml/2007/1/29/345)
> (among other things).
> 
> Is that project still active?  Do things still move through staging as
> originally intended?  Am I conflating two different things?

I'll let Greg answer.

> I'm not sure if Intel's driver qualifies as a Free Linux Driver project or
> not.

$ git show a49d25364dfb | diffstat -s
 920 files changed, 204645 insertions(+)

That may be part of the answer :-)

> I can think of other companies, less experienced with kernel work than
> Intel, that might still benefit from the Free Linux Driver project, and
> staging.
> 
> I thought the whole idea of staging was that something was better than
> nothing, and that cruddy code could be taken even if the hardware vendor
> didn't have the skills or inclination to do proper mainlining.

I'd say that in that case staging doesn't work for the company's benefit, but 
for the community's benefit. For smaller drivers that are deemed useful by the 
community, when the company manufacturing the hardware isn't helpful 
(regardless of the reason, I'm not trying to blame anyone here), and if there 
are community members willing and able to do the work, staging is certainly 
helpful, and better than nothing. For a 200k+ lines of code driver in a very 
bad state to start with, I can't really picture how anything could be done in 
someone's free time.

I don't know how the atomisp ended up in staging and whether it was an attempt 
from Intel to tick a "upstream driver" box or not, but one thing that is clear 
is that they haven't put the necessary resources behind it.

-- 
Regards,

Laurent Pinchart

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

[Mauro Carvalho Chehab]

Em Mon, 10 Sep 2018 19:22:05 +0000
<Tim.Bird@sony.com> escreveu:

> > -----Original Message-----
> > From: Laurent Pinchart
> > 
> > On Monday, 10 September 2018 21:52:30 EEST Takashi Iwai wrote:  
> > > 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.  
> > > >  
> ...
> > > > > - 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?  
> > 
> > Intel pushed a huge code drop that clearly required a staging period, and
> > then
> > simply left it bitrot. No developer was committed to perform the work
> > needed
> > to de-stage the driver. I don't know whether priorities had changed internally
> > or if there were no resources from day 1, but in the end it's pretty clear
> > that if we had known beforehand of the outcome, the driver would likely not
> > have been even a staging candidate.
> >   
> > > 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.  
> > 
> > Anti-pattern number one: push a large driver to staging knowing that you
> > won't
> > work on it anymore, and expect the community to do your work for free.
> > 
> > I would have expected a company like Intel to know better. Or, rather sadly, I
> > probably have given up on such expectations already :-S  
> 
> I thought staging was where work was done on drivers that were submitted
> to Greg's Free Linux Driver project (https://lkml.org/lkml/2007/1/29/345)
> (among other things). 
> 
> Is that project still active?  Do things still move through staging as originally
> intended?  Am I conflating two different things?
> 
> I'm not sure if Intel's driver qualifies as a Free Linux Driver project or not.
> I can think of other companies, less experienced with kernel work than Intel,
> that might still benefit from the Free Linux Driver project, and staging.
> 
> I thought the whole idea of staging was that something was better than nothing,
> and that cruddy code could be taken even if the hardware vendor didn't have
> the skills or inclination to do proper mainlining.

I guess the submitter had the intention to maintain it, but then Spectre
and Meltdown happened and he had to shift to do something else.

IMHO, it doesn't really matter if the driver to be placed in staging is
coming from the Free Linux Driver project or from anyone else.
For me, the major requirement is that, by the time it is submitted, 
someone should want to make it to follow the upstream rules. If not,
well, we can just drop it after a while.

That's said, I would be expecting (or either desiring) that a vendor that
works well with the community on other areas would have developed 
a camera driver using upstream first approach, but we know that
not all development teams think the same.

Thanks,
Mauro

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

[Greg KH]

On Mon, Sep 10, 2018 at 07:22:05PM +0000, Tim.Bird@sony.com wrote:
> 
> 
> > -----Original Message-----
> > From: Laurent Pinchart
> > 
> > On Monday, 10 September 2018 21:52:30 EEST Takashi Iwai wrote:
> > > 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.
> > > >
> ...
> > > > > - 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?
> > 
> > Intel pushed a huge code drop that clearly required a staging period, and
> > then
> > simply left it bitrot. No developer was committed to perform the work
> > needed
> > to de-stage the driver. I don't know whether priorities had changed internally
> > or if there were no resources from day 1, but in the end it's pretty clear
> > that if we had known beforehand of the outcome, the driver would likely not
> > have been even a staging candidate.
> > 
> > > 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.
> > 
> > Anti-pattern number one: push a large driver to staging knowing that you
> > won't
> > work on it anymore, and expect the community to do your work for free.
> > 
> > I would have expected a company like Intel to know better. Or, rather sadly, I
> > probably have given up on such expectations already :-S
> 
> I thought staging was where work was done on drivers that were submitted
> to Greg's Free Linux Driver project (https://lkml.org/lkml/2007/1/29/345)
> (among other things). 
> 
> Is that project still active?  Do things still move through staging as originally
> intended?  Am I conflating two different things?

Yes, the project is still active, and yes, things still move through
staging as originally intended.

> I'm not sure if Intel's driver qualifies as a Free Linux Driver project or not.
> I can think of other companies, less experienced with kernel work than Intel,
> that might still benefit from the Free Linux Driver project, and staging.
> 
> I thought the whole idea of staging was that something was better than nothing,
> and that cruddy code could be taken even if the hardware vendor didn't have
> the skills or inclination to do proper mainlining.

Yes, that is true, but is not what happened here.  A developer from
Intel asked that this driver be submitted, and I took it with the
intention that it still be worked on to be "cleaned up properly".  That
happened a bit, and then it seems that the resources at Intel shifted
and the driver became abandoned.

Because it was abandoned, the code was dropped from the kernel.  If
anyone wishes to pick up the work in the future, a simple 'git revert'
will get you there and away you can go.

So this was an example of everything working "properly" as far as I can
tell.

thanks,

greg k-h