Date:	Wed, 18 Jun 2008 20:30:02 +0300
From:	Benny Halevy <bhalevy@...asas.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	ksummit-2008-discuss@...ts.linux-foundation.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Request for discussion on when to merge drivers

On Jun. 18, 2008, 18:27 +0300, James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> 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?

This is a very good idea.

Exposing the not-yet-ready-to-be-released code to linux-next will
expose conflicts earlier, and hopefully in smaller, more manageable
deltas.

However, some projects that need staging may change kernel APIs
to such extent that including them in linux-next will require
committing to the API changes in the -next time frame.  If that's
a problem, staging them in the maintainer's tree may still be valuable.

Benny

> 
> James
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists