Thread (21 messages) 21 messages, 10 authors, 2012-11-15

Re: linux-next: Tree for Nov 14

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2012-11-14 07:24:11
Also in: lkml

On Wed, 14 Nov 2012 18:15:36 +1100 Stephen Rothwell [off-list ref] wrote:
Hi Andrew,

On Tue, 13 Nov 2012 22:56:35 -0800 Andrew Morton [off-list ref] wrote:
quoted
On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar [off-list ref] wrote:
quoted
* Andrew Morton [off-list ref] wrote:
quoted
It would help if the old sched/numa code wasn't in -next while 
you're away.  That would give me a clean run at 3.7 and will 
make it easier for others to integrate and test the four(!) 
different autoschednumacore implementations on top of 
linux-next.

Pretty please?
The next integration should have this solved: I have removed the 
old sched/numa bits, replaced by the latest rebased/reworked 
numa/core bits.
That solves one problem, but I still need to route around the numa
stuff when preparing the 3.8-rc1 merge.  Again!
I am not sure what is actually involved here, but would it help if I
made you a new akpm-base with the old tip tree replaced by the new one
that Ingo just pushed out?  Or are there still problematic things in the
tip tree?
If this new code is targeted at 3.9 as I'm suggesting then it should go
into -next after 3.8-rc1, so the sched/numa part of -tip should be
omitted from -next until then.

If instead the plan is to merge it all into 3.8 then -tip should go
into -next as-is.

How's your crystal ball?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help