linux-kernel - Re: linux-next: Tree for Nov 14

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFzY0+epP2Dxj=ghwVB3=JbM=qXC6a5V2kf9EzD_E-79tA@mail.gmail.com>
Date:	Wed, 14 Nov 2012 09:19:16 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Hugh Dickins <hughd@...gle.com>
Subject: Re: linux-next: Tree for Nov 14

On Tue, Nov 13, 2012 at 10:56 PM, Andrew Morton
<akpm@...ux-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/