|| ||Andrew Morton <akpm-AT-linux-foundation.org> |
|| ||Ingo Molnar <mingo-AT-kernel.org> |
|| ||Re: linux-next: Tree for Nov 14 |
|| ||Tue, 13 Nov 2012 22:56:35 -0800|
|| ||Stephen Rothwell <sfr-AT-canb.auug.org.au>,
Ingo Molnar <mingo-AT-elte.hu>, Hugh Dickins <hughd-AT-google.com>|
|| ||Article, Thread
On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar <email@example.com> wrote:
> * Andrew Morton <firstname.lastname@example.org> wrote:
> > On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell <email@example.com> wrote:
> > > News: next-20121115 (i.e. tomorrow) will be the last release until
> > > next-20121126 (which should be just be after -rc7, I guess - assuming
> > > that Linus does not release v3.7 before then), so if you want something
> > > in linux-next for a reasonable amount of testing, it should probably be
> > > committed tomorrow.
> > 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!
And yes, I'm assuming you're not targeting 3.8. Given the history
behind this and the number of people who are looking at it, that's too
hasty. Hugh can speak to his own reasons for feeling the same way.
And I must say that I deeply regret not digging my heels in when this
went into -next all those months ago. It has caused a ton of trouble
for me and for a lot of other people.
Put it in -next after 3.8-rc1 with a view to a 3.9 merge, please.
to post comments)