Grant Grundler wrote:
On Wed, May 17, 2006 at 07:40:07AM -0700, Roland Dreier wrote:
Yes, I agree.  That's why I think we should get rid of the
"linux-kernel" part of the svn tree entirely.  Because everyone who
wants to test new code seems to run last stable kernel + svn drivers
instead of the new development kernel.

That's because openib guarantee SVN drivers will build with last
stable kernel. Change that policy and document the steps
that folks should follow. I'd be willing to occasionally try
newer kernels if you think that's what we should be doing.

Please note that both approaches suggested above will not force to test latest IB code with the under-development kernel...

This is b/c most of the code (specifically the already in-tree) has zero backport to the latest stable kernel, eg the kernel portion of OFED which is targeted for 2.6.16 is based on the for-2.6.17 branch of Roland's GIT tree (expect for the components not there yet, which are co from the SVN), but OFED is not tested with (does not support) 2.6.17-rcX

The same "trick" would work also with Grant's approach.

So there's no replacement for testing done at least by the openib maintainers (and distros!!! when they start moving to IB...) for:

+1 next-kernel-RC-versions downloaded from kernel.org (eg 2.6.17-RCX)
+2 next-next-kernel-branches of infiniband.git (Roland's tree)

Ofcourse people are busy, and testing is derived from needs.. for example the iSER maintainers (...) are testing now with what's closet to 2.6.18 and i guess the ipath maintainers are testing with 2.6.17-rc4

But at some point of the cycle, its a must that each maintainer would test his/her code with next-kernel-RC-versions from kernel.org

Or.

Or.

_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to