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

[Steve Wise]

On Thu, 2006-09-28 at 14:00 -0700, Roland Dreier wrote:
>     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?? **
> 

Perhaps "latest" was a bad word.

> Does someone who wants to check if the new ipath tree fixed a bug
> really want to run my bleeding-edge IPoIB NAPI stuff?  

No, they just want to test a bug in the ipath code.   They don't care
about iwarp or rdma cm probably either.

> Does someone
> who wants to try IPoIB NAPI want to run possibly-broken bleeding edge
> RDMA CM code?  etc. etc.
> 

Right,  there are users who DONT want that.  But there are users who
want:  dapl + user mode rdma cm + user mode iwarp + rdma cm kernel +
iwarp kernel + chelsio driver + ipath driver, for example.  They should
be able to pull these into a single tree and build it somehow.
Previously it was easy because everyone pushed their code into the svn
repos.  With the changing focus on feeding things into kernel.org I
think we need a new process. 

>     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.
> 

ok.  topic branches in your git tree or a set of git trees sounds
reasonable.    But to facilitate those trying to assemble bits and
pieces, we should provide documentation on where they get this stuff.
This _might_ help convince those who are hanging on to the svn idea to
adopt this new scheme...

Steve.