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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
