Re: [GIT PULL] Namespace file descriptors for 2.6.40

[Ingo Molnar <mingo@elte.hu>]

* James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> Traditionally, the arch trees tend to go a bit later because they wait to see 
> if there's any fallout from x86; [...]

Not really - most of the arch trees 'traditionally' went late even when the x86 
tree itself was monolithic and was itself sent late in the merge window (with 
the notable exception of the powerpc tree).

> [...] but this time, I think it looks OK, [...]

That's not really a surprise, there hasn't been a serious 'problem' with the 
x86 tree for a long time, roughly since we switched to the finegrained Git 
topical split-up maintenance model about two years ago.

[ That split-up also means that there is no 'x86 tree' anymore as such: if you 
  check lkml we send roughly 20-30 independent trees in the merge window and 
  have done that for the past ~10 kernel cycles. ]

In fact exactly *because* there's few problems with the x86 topic trees can we 
push them so soon: if problems were frequent then 1) we would not be able to be 
ready on time and 2) i suspect we'd be pulled in later in the window as well as 
a maintainer generally wants to pull low risk items first, high risk items 
last, to maximize the utilization of testing capacity.

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.

Also, system call table conflicts are trivial to resolve. Merging in net-next 
to avoid such a conflict is like cracking a nut with a sledgehammer.

Thanks,

	Ingo