Re: linux-next: Tree for Nov 14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 13, 2012 at 10:56 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> 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-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux