Re: [git pull] x86 updates for v2.6.30, final bits

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 28 Mar 2009, Ingo Molnar wrote:
> > 
> > [ The sched.c bit is an odd one out: due to previous cpumask changes 
> >   it developed a dependency/conflict on the cpumask tree which 
> >   depended on the x86 tree. Should i have started a separate branch 
> >   for it? I didnt want to merge the x86 tree into the scheduler 
> >   tree. We had really excessive dependencies and cross-merges in
> >   this cycle around the x86 tree and i very much hope this is an
> >   exception
> 
> The problem is that you've been hoping for this "exception" for 
> the last three kernel releases.
> 
> The details differ, but you do seem to mix things up too much. I'm 
> not at all happy. I think quality control is slipping, because 
> there's this absolutely _humongous_ amount of crap that gets in 
> through you. You seem to have a hard time saying "no".
> 
> And yes, you boot-test things pretty well, but I really wish you 
> had more focus. This "everything under the sun" thing is very 
> annoying, and I think you are too damn eager to merge the random 
> new feature of the day.
> 
> So instead of "hoping", how about you look at making sure it 
> really _does_ become an exception. And that really fundamentally 
> means that it can't happen every release.
> 
> How about trying one release to just say "no" if you start seeing 
> all these kinds of things. We don't allow non-x86 architectures to 
> just tie things together this way. The fact that you have the same 
> tree seems to just encourage badness by making it "easier" to just 
> mix things up.

Yes, will do that - sorry about this. We'll also take more care and 
will try to cook up more scripting to make sure such crappy-looking 
circular criss-cross merges and compound trees dont happen again.

The remaining trees we have for this merge window are all 
single-purpose. We sent five of them in the last couple of hours and 
they have the kind of structure that we intend to use in the future 
too. If you still see _any_ problems with them, please let me know 
so i can fix the workflow ASAP.

	Ingo