Re: [Ksummit-2008-discuss] Request for discussion on when to mergedrivers

[James Bottomley]

On Thu, 2008-06-19 at 09:31 +1000, Benjamin Herrenschmidt wrote:
> > 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?
> 
>  .../...
> 
> linux-next should, imho, exclusively be for things we are pretty much
> commited to merge in the next release. ie, a staging place to fixup
> things like build breakages, patch conflicts, etc...
> 
> Or else, it will just be another -mm ....

Well, as Greg said for his driver staging tree, I think we can elide
this requirement for new drivers.  The good thing about drivers is that
there's nothing we're really doing to break anything: before the driver
the hardware was just plane unusable with Linux after the driver well,
we're hoping it might be ...

> So while what you say makes sense, I think we should only put drivers in
> once we have pretty much decided that the drivers in question would be
> merged... in which case, why not straight upstream ?

The reason for staging early in linux-next is twofold

     1. We want to encourage the driver submitter that something is
        being done
     2. we want to make the driver available to a pool of testers who
        might have the hardware but might not otherwise find it so they
        can report errors that aren't picked up via the normal code
        inspection and analysis methods.

Arguably, I can do this by putting it into my upstream tree (which feeds
into linux-next) the reason for not doing so is that Linus likes us to
preserve history in there when we can.  If I need to pull the driver for
a reroll it really screws the git history (plus makes it hard for me).
If it's in its own branch, I can toy with it as much as I need to
without affecting my upstream tree.  Plus the commitment is that
anything which goes into my upstream tree should be for the next merge
window.  A driver with substantive code issues (or which shows problems
under test) might not be such a candidate until the issues are sorted
out.

James


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