Messages in this thread | | | Date | Wed, 18 Jun 2008 20:30:02 +0300 | From | Benny Halevy <> | Subject | Re: Request for discussion on when to merge drivers |
| |
On Jun. 18, 2008, 18:27 +0300, James Bottomley <James.Bottomley@HansenPartnership.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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
| |