Messages in this thread | | | Subject | Re: [GIT PULL] Namespace file descriptors for 2.6.40 | From | James Bottomley <> | Date | Tue, 24 May 2011 11:26:21 +0400 |
| |
On Tue, 2011-05-24 at 00:03 -0700, Eric W. Biederman wrote: > Ingo Molnar <mingo@elte.hu> 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
| |