[openib-general] [RFC] remove kernel drivers from svn

[Grant Grundler]

On Thu, Apr 20, 2006 at 09:39:56AM -0700, Roland Dreier wrote:
> I guess I was trying to say that Linus's tree is really the kernel
> repository.  Trying to pretend that our kernel drivers are independent
> of the kernel leads to a very confusing situation.

openib SVN tree is the equivalent to -mm trees and many other
public trees used for developement. parisc-linux isn't ready
to obsolete it's developement tree because of significant outstanding
differences with linus/andrew.  ia64-linux tree has been obsoleted.
Tony Luck (ia64 maintainer) on maintains a patch tree like you are suggesting.
I don't know where openib devel falls between those two and how
the next round of "transport neutral" changes will affect the tree.

> I would really like to see people who want to run bleeding-edge stuff
> grab something along the lines of
> http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.17-rc2-git2.bz2
> or if they're very brave pull my for-2.6.18 or for-mm tree.  Otherwise
> we end up wasting their testing attention on something different from
> the upstream kernel.

If using quilt or git makes that easy, that's fine with me.
Update the wiki or "How to test this" web pages with the replacement
to SVN.

I'll also note that moving away from SVN will cause some turmoil
for the Windows OpenIB efforts.

You have to trade off how hard it is to test the developement
trees (ie how easy is it to update/pull patches and integrate with
a tree from linus) vs merging suitable patches back to linus.
This size and number of patches outstanding at any given
time should be a clue how well this might work.

I also think testing upstream kernels isn't realistic for "the
general population" since folks (a) need the HW and (b) some easy
to run (test) applications.

Asking openib developers to test both upstream and developement trees
isn't realistic IMHO. Don't forget that they eventually end up testing
multiple distro trees (SuSE/RH) as well. But I know the risks of not
testing kernel.org trees - those bits eventually land in a distro.

hth,
grant