[openib-general] 2.6.18 kernel support in the main trunk.

[Roland Dreier]

    Steve> So I think we all agree on the need for a way to get a
    Steve> "latest" snapshot of the kernel code (we argue a LOT about
    Steve> how this is done :).

Not to be difficult -- but I disagree.  I think this statement doesn't
actually make sense, because: ** what does "latest" mean?? **

Does someone who wants to check if the new ipath tree fixed a bug
really want to run my bleeding-edge IPoIB NAPI stuff?  Does someone
who wants to try IPoIB NAPI want to run possibly-broken bleeding edge
RDMA CM code?  etc. etc.

    Steve> The model we should adopt IMO is: linus's git tree + some
    Steve> set of patches that compose the latest open fabrics kernel
    Steve> code.  The patches are all in-process for going into
    Steve> linus's tree at some point.  And the maintainer of that
    Steve> technology, (eg sean for ucma) will keep that patch set up
    Steve> to date for folks to pull until it gets pulled into an
    Steve> upstream git tree (like linus's or roland's).  With git and
    Steve> stg this is pretty easy IMO.

Well, I think that's sort of reasonable, except that it has to be more
than one git branch.  All the in-process stuff should be on logically
separate "topic branches".  I'm happy to maintain for-2.6.x trees that
represent stuff queued for the current and next kernel release, but
stuff that hasn't been fully stabilized and reviewed should be kept
separate, and I'm happy to create branches in my git tree for any
other patch sets for developers who don't want to use git or don't
have a place to host things.

 - R.