On Tue, 2011-05-24 at 00:03 -0700, Eric W. Biederman wrote: > Ingo Molnar <mingo@xxxxxxx> writes: > > > I agree with Linus's notion in this thread though, a core kernel change should > > generally not worry about hooking up rare-arch system calls (concentrate on the > > architectures that get tested most) - those are better enabled gradually > > anyway. > > The way I read it he was complaining about my having parisc bits and > asking for my branch to be merged before the parisc bits had been > merged. Which I credit as a fair complaint. If I am going to depend on > other peoples trees I should wait. > > At the same time when I am busy looking for every possible source of > trouble and putting code into net-next to detect pending conflicts, > and when maintainers complain when I ask for review that my patches > conflict with their patches. Being a contentious developer I am > inclined to do something. Right ... and the problem is that someone has to care, because the conflict will show up in linux-next. I think Stephen Rothwell would appreciate us making his life easier rather than leaving it to him to sort out the problems. > Now that the reality has sunk in that it means waiting for other peoples > code to be merged before I request for my changes to be merged I don't > think I will structure a tree that way again while I remember. Right. This is quite a common occurrence in SCSI (mostly changes entangled with block or libata). If you don't feel comfortable running a postmerge tree, just send me the bits and I'll do it (after all it works either way around: I can pull in the syscalls and depend on your tree rather than vice versa). James _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
