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

[Matt Leininger]

  If we move forward with a git repository then we should move all
kernel code into git.  I don't want to get into a situation where kernel
components are spread out over various repositories and servers.  I'm
all for making your development lives easier.  The entire development
tree has gotten very confusing over the past few months.  The ipath
driver is never up to date (therefore it's always broken).  Iwarp is
upstream but not in the main line development tree.  If a simpler
process can fix this then I'm all for it.

  So what it your proposal (Roland and Bryan)?  Do you want to move all
kernel development into Roland's git tree, and have the user space code
stay in svn (at least for the time being)?  This would allow OFED
releases to be pulled direct from Roland's git tree (kernel) and the
openfabrics svn (user space).   BTW if it is useful we can set up a git
repository on openfabrics once we move the server to its new provider.

 Thanks,

  - Matt



On Thu, 2006-09-28 at 09:31 -0700, Bryan O'Sullivan wrote:
> On Thu, 2006-09-28 at 12:21 -0400, James Lentini wrote:
> 
> > As a user of the SVN repository, I'm confused about what this means 
> > going forward. 
> > 
> > Are you going to completely remove the mthca and ipath code from SVN 
> > or just stop updating the code that is there?
> 
> I will let Roland speak for the mthca driver, but we have stopped
> maintaining the ipath driver in the SVN tree, and I expect that we will
> remove it entirely in perhaps a month or so.
> 
> > Will the other components that are upstream (SRP, iSER, IPoIB, CM, 
> > RDMA CM, SA, MAD, CORE, ...) be removed? What rules are you using to 
> > determine if the SVN version will be kept up to date?
> 
> I have no stake in what happens to those components, but I would not
> personally mind if they moved into Roland's git tree.  I don't care for
> git, but I vastly prefer using it to waiting for SVN.
> 
> > In the future, how will users work 
> > with new features that are not yet upstream?
> 
> One possibility would be to pull the same components out of a branch of
> a git tree; same procedure, different source.
> 
> 	<b
> 
> 
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>