[lkml]   [2008]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRequest for discussion on when to merge drivers
    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:

    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?


     \ /
      Last update: 2008-06-18 17:31    [W:0.041 / U:38.952 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site