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

[Steve Wise]

On Thu, 2006-09-28 at 10:31 -0700, Roland Dreier wrote:
>  > I have said this before, but I will repeat myself once again.
>  > I really do not care where the latest code is, but there needs
>  > to be ONE place where we can get all the latest code for development
>  > and testing.
> 
> I'll repeat my usual response: the notion of a single "latest" tree
> doesn't match reality, and any attempt to coerce things into that mold
> just causes problems.  There's not necessarily any correlation between
> the newest ipath code and Sean's RDMA CM.
> 
> git (or any other true distributed SCM system) makes this easier to
> handle: you can easily merge the branches you're interested in trying
> into your local tree.
> 
>  - R.

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

And at this point in time its definitely _not_ the svn trunk for some
kernel components.  Like infiniband/core, which is behind linus's git
tree for some things (eg iwarp), and ahead of linus's git tree for
others (eg ucma).  This is bad.  There's no way to get the latest code
with all features (eg iwarp + user cma).

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

So the kernel developers all adopt git and maintain their latest changes
that are always on top of linus's git tree, or roland's infiniband git
tree.  And we document where each component's patches or git tree is
located.  Perhaps on the openib wiki.  

OFED and others who build snapshots will have to pull from these
different components, merge them, test them, then release it as a
"snaphot".

Here is what we did for iwarp, which is an example of one of these
components:


Setup initial patch set:

- clone linus's git tree 

- clone roland's git tree and reference linus's tree

- create your stacked patchset


Whenever you want to get upstream updates from roland's tree and/or
linus's tree you do this:

- pop your patchset

- git pull from linus's tree to update your clone of his git tree.

- re-clone roland's tree again referencing linus's tree (this makes the
operation quicker). 

- push (and merge) your patchset back on top 


Dunno if all this helps the conversation, but we've argued about it for
a long time, and I thought maybe getting more specific on process and
how to maintain patches might help move things along...
 

STeve.