From: Greg KH <gregkh@linuxfoundation.org>
To: Tim.Bird@sony.com
Cc: mchehab+samsung@kernel.org, ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] How can we treat staging drivers better?
Date: Tue, 11 Sep 2018 11:13:23 +0200 [thread overview]
Message-ID: <20180911091323.GA26421@kroah.com> (raw)
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF7C1DEDA0@USCULXMSG01.am.sony.com>
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
prev parent reply other threads:[~2018-09-11 9:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 13:35 [Ksummit-discuss] [MAINTAINER SUMMIT] How can we treat staging drivers better? Takashi Iwai
2018-09-05 13:55 ` Dan Carpenter
2018-09-05 14:03 ` Takashi Iwai
2018-09-05 14:20 ` Greg KH
2018-09-05 14:41 ` Takashi Iwai
2018-09-05 14:59 ` Shuah Khan
2018-09-05 14:51 ` Andrew Lunn
2018-09-05 14:59 ` Joe Perches
2018-09-05 14:08 ` Sean Paul
2018-09-05 14:22 ` Greg KH
2018-09-05 14:29 ` Sean Paul
2018-09-05 15:35 ` Daniel Vetter
2018-09-05 16:21 ` James Bottomley
2018-09-05 16:35 ` Daniel Vetter
2018-09-07 19:44 ` Mauro Carvalho Chehab
2018-09-08 8:45 ` Jonathan Cameron
2018-09-10 18:49 ` Takashi Iwai
2018-09-10 18:52 ` Takashi Iwai
2018-09-10 18:58 ` Laurent Pinchart
2018-09-10 19:22 ` Tim.Bird
2018-09-10 20:51 ` Laurent Pinchart
2018-09-11 0:30 ` Mauro Carvalho Chehab
2018-09-11 9:13 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180911091323.GA26421@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Tim.Bird@sony.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mchehab+samsung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).