From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: ksummit-2008-discuss@lists.linux-foundation.org
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Request for discussion on when to merge drivers
Date: Wed, 18 Jun 2008 10:27:46 -0500 [thread overview]
Message-ID: <1213802866.3515.24.camel@localhost.localdomain> (raw)
There have been a large number of emails on lkml (too many for me to
dredge up and quote) plus a fair few private ones on the subject of when
to merge drivers. The opinions seem to vary from "immediately they show
up on the mailing list" to " after we're sure they're demonstrated to be
working and maintainable". The fact that the arguments have been going
round and round on the various mailing lists without generating any
consensus would seem to indicate the topic would benefit from some face
to face discussion time.
I think the Kernel Summit would be a good place to have a discussion of
what the criteria are for merging a driver (even if, in the end, it's at
the discretion of the subsystem maintainers).
I think everyone agrees that we can't put just anything that appears on
the mailing list in the tree, since they all have to be at least code
inspected and be checked for the usual errors, omissions and root holes.
However, disagreements seem to set in after this.
For the record, my own view is that when a new driver does appear we
have a limited time to get the author to make any necessary changes, so
I try to get it reviewed and most of the major issues elucidated as soon
as possible. However, since the only leverage I have is inclusion, I
tend to hold it out of tree until the problems are sorted out.
Experience has shown that for most SCSI drivers, the authors tend to be
the people producing the hardware and without documentation, no-one else
can fix up anything other than obvious coding errors, so we can't put it
in the tree and hope someone else will fix it if they have a problem.
One possible way of doing this is certainly to put the drivers in the
staging tree:
http://marc.info/?l=linux-kernel&m=121312896923196
The only slight wrinkle (at least for me) is that often the process of
cleaning up a driver is fairly intensive for a maintainer and turn
around is a lot faster if you're doing it in a tree you control. (All
the scsi drivers we've done like this have lived in temporary branches
while they were being worked on). So perhaps in addition we should be
encouraging maintainers to run staging branches under similar rules in
the staging tree, but allowing inclusion into linux-next?
James
next reply other threads:[~2008-06-18 15:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-18 15:27 James Bottomley [this message]
2008-06-18 17:15 ` [Ksummit-2008-discuss] Request for discussion on when to merge drivers Luck, Tony
2008-06-18 17:34 ` James Bottomley
2008-06-18 17:30 ` Benny Halevy
2008-06-18 23:20 ` [Ksummit-2008-discuss] " Jiri Kosina
2008-06-19 7:34 ` Benny Halevy
2008-06-18 18:38 ` Mauro Carvalho Chehab
2008-06-18 23:31 ` Benjamin Herrenschmidt
2008-06-18 23:39 ` [Ksummit-2008-discuss] " James Bottomley
2008-06-18 23:48 ` Jiri Kosina
2008-06-19 9:13 ` Stefan Richter
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=1213802866.3515.24.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=ksummit-2008-discuss@lists.linux-foundation.org \
--cc=linux-kernel@vger.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