linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, Hugh Dickins <hughd@google.com>
Subject: Re: linux-next: Tree for Nov 14
Date: Wed, 14 Nov 2012 09:19:16 -0800	[thread overview]
Message-ID: <CA+55aFzY0+epP2Dxj=ghwVB3=JbM=qXC6a5V2kf9EzD_E-79tA@mail.gmail.com> (raw)
In-Reply-To: <20121113225635.a848fd6c.akpm@linux-foundation.org>

On Tue, Nov 13, 2012 at 10:56 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> That solves one problem, but I still need to route around the numa
> stuff when preparing the 3.8-rc1 merge.  Again!

Btw - and this is tangential/unrelated - I really think that your
should strive to *not* base -mm on top of next, but instead put it on
top of the release kernel.

The "on top of next" approach not only causes you continual problems
like the above, it also causes the (related) problem that your email
patch-bombs always tend to be fairly late in the merge window, because
you need to wait for the big parts of linux-next to have hit my tree.

So it's more work for you, and it actually causes merge problems for me too.

I realize that you want to test a "everything" kernel, but at the same
time, that's actually counter-productive. It means that your tree ends
up depending on others, and you have to fight bugs that aren't even
necessarily yours at all.

And in this particular case, it would be easier for the NUMA people,
since your patches would presumably contain Mel's work, so they could
more easily rebase on top of your work, rather than the current
situation which is ass-backwards and has fundamental odering problems:
you want to base your stuff on linux-next, people want to put their
numa stuff into linux-next, and you have a bad circle.

Of course, people who want to base their work on top of Mel's code
often are git users already, so now they'd want a stable git tree
(non-rebased) to work on top, so they'd have problems with -mm anyway.
I don't know if Mel is a git user at all (there are no commits in the
kernel tree that are done by Mel, but maybe Mel has used git
elsewhere), but in this case maybe it would be a possibility that
Mel's NUMA patches could be done as one single stable -git branch, and
come into -mm (and linux-next) that way?

So I really think it would be much nicer if you just did your tree
directly on top of mine, instead of on top of linux-next. It would
make everything easier for everybody.

Of course, if you then want to test the combined thing, that's fine,
but that merging is also something that git is pretty good at. You
could just check the linux-next tree itself, since then Stephen would
have done the merging for you.

                  Linus

  parent reply	other threads:[~2012-11-14 17:19 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-14  5:30 linux-next: Tree for Nov 14 Stephen Rothwell
2012-11-14  5:37 ` Andrew Morton
2012-11-14  5:53   ` Andrew Morton
2012-11-14  6:47   ` Ingo Molnar
2012-11-14  6:56     ` Andrew Morton
2012-11-14  7:15       ` Stephen Rothwell
2012-11-14  7:24         ` Andrew Morton
2012-11-14  7:39       ` Ingo Molnar
2012-11-14  8:13         ` Hugh Dickins
2012-11-14 17:05           ` Rik van Riel
2012-11-15 12:10             ` Mel Gorman
2012-11-14 17:19       ` Linus Torvalds [this message]
2012-11-14  6:55   ` Stephen Rothwell
2012-11-14  7:03     ` Stephen Rothwell
2012-11-14 19:41 ` linux-next: Tree for Nov 14 (gpu/drm/i915) Randy Dunlap
2012-11-14 20:17   ` Andrew Morton
2012-11-15  0:59 ` [PATCH 1/2] asm-generic: add __WARN() to bug.h Randy Dunlap
2012-11-15  1:28   ` David Rientjes
2012-11-15  0:59 ` [PATCH 2/2] mm: balloon_compaction.c needs asm-generic/bug.h Randy Dunlap
2012-11-15  1:29   ` David Rientjes
2012-11-15  1:29     ` Randy Dunlap
  -- strict thread matches above, loose matches on Subject: below --
2023-11-14  3:19 linux-next: Tree for Nov 14 Stephen Rothwell
2022-11-14  7:49 Stephen Rothwell
2019-11-14  8:31 Stephen Rothwell
2019-11-14 18:38 ` Naresh Kamboju
2019-11-14 20:11   ` Jan Stancek
2019-11-14 21:19     ` Arnd Bergmann
2018-11-14  5:26 Stephen Rothwell
2017-11-14  6:20 Stephen Rothwell
2016-11-14  7:23 Stephen Rothwell
2014-11-14  8:27 Stephen Rothwell
2014-11-15 21:19 ` Guenter Roeck
2014-11-16  2:33   ` Jiang Liu
2014-11-16  3:22     ` Guenter Roeck
2014-11-16  4:20       ` Jiang Liu
2014-11-16  6:56         ` Guenter Roeck
2014-11-16  8:24           ` Jiang Liu
2014-11-16  8:37             ` Jiang Liu
2014-11-16 15:42               ` Guenter Roeck
2014-11-16 16:01             ` Guenter Roeck
2014-11-16 16:11               ` Guenter Roeck
2014-11-17  5:12       ` Jiang Liu
2014-11-17 17:02         ` Guenter Roeck
2013-11-14  4:22 Stephen Rothwell
2011-11-14  3:43 Stephen Rothwell
2019-11-14 16:43 ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+55aFzY0+epP2Dxj=ghwVB3=JbM=qXC6a5V2kf9EzD_E-79tA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@kernel.org \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).