From: Takashi Iwai <tiwai@suse.de>
To: ksummit-discuss@lists.linuxfoundation.org
Subject: [Ksummit-discuss] [MAINTAINER SUMMIT] How can we treat staging drivers better?
Date: Wed, 05 Sep 2018 15:35:53 +0200 [thread overview]
Message-ID: <s5hbm9ccbie.wl-tiwai@suse.de> (raw)
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
next reply other threads:[~2018-09-05 13:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 13:35 Takashi Iwai [this message]
2018-09-05 13:55 ` [Ksummit-discuss] [MAINTAINER SUMMIT] How can we treat staging drivers better? 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
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=s5hbm9ccbie.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=ksummit-discuss@lists.linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.