Thread (1 message) 1 message, 1 author, 2011-05-24

Re: [GIT PULL] Namespace file descriptors for 2.6.40

From: Eric W. Biederman <hidden>
Date: 2011-05-24 08:11:32
Also in: lkml

James Bottomley [off-list ref] writes:
On Tue, 2011-05-24 at 00:03 -0700, Eric W. Biederman wrote:
quoted
Ingo Molnar [off-list ref] writes:
quoted
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
                                         ^^^^^^^^^^^ conscientious
I didn't realize it was possible to make that typo.
quoted
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.
quoted
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).
Well for the moment I don't see too many problems.  I sent another pull
request to Linus earlier today now that your changes are in.  So I am
hoping either Linus will pull my tree or someone will educate me on what
he will Linus will accept.

Right now my tree is tested and in a good state.  Heck I'm running it
to send this email.  So I am reluctant to change anything without clear
feedback.

James when you refer to a postmerge tree what are the dynamics/semantics
usually associated with that?  Is this a tree that gets pulled a couple
of times?  Once with the non-conflicting bits.  Another time when the
bits it depends on have been merged?  Or is this a tree that gets pulled
after the merge window entirely?

Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help