Message-ID: <CA+55aFzytqbGcOzWvYAo-EnJCeK5mFqdCF5OjMTeM5UBfeyCXw@mail.gmail.com>
Date:	Mon, 7 Nov 2011 18:10:02 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Linux 3.2-rc1

So it's been two weeks since 3.1, and you know how it works by now.

I have to say, this wasn't my favorite merge window ever. I really
wanted to take only things that had been in -next, but verifying it
was fairly painful, since a lot of the trees had been rebased, and the
ones that hadn't been rebased often had some extra patches that still
showed up when I did my "git log linux-next..FETCH_HEAD" thing.

On the whole, most of it was all good, and I didn't really end up
complaining to people. I'm pretty sure that there were trees I
shouldn't have let through, but the majority really had been in -next.

The other point of irritation was that there really was a lot of stuff
that came in yesterday and basically treated the merge window as some
kind of high-tech limbo dance. If it hadn't been for a few trees I
wanted to pull, I had actually planned to do the -rc1 release Sunday
afternoon instead, just to cut those annoying last-minute pull
requests off.

And some trees didn't get pulled. You know who you are, and you can
try to appeal to my softer side if you think it was unfair. Of course,
if you *do* find my softer side, please tell my wife and kids too,
they'll be thrilled.

But the main reason some trees didn't get pulled was that they
generated long flame-wars, and I just felt like I really didn't need
the aggravation this time around, especially as I knew I had plenty
other trees to pull.

What *did* get pulled? A lot. The diffstat is huge, and is full of
renames. The network drivers got re-organized, which is a big chunk of
the renames, but there are architecture cleanups and re-organizations
there too (UML and some arm sub-architectures, for example) adding
their own set of renames. Along with some staging drivers that got
upgraded to non-staging etc etc.

Which brings me to a question I already asked on G+ - do people really
need the old-fashioned patches? The -rc1 patch is about 22MB gzip-9'd,
and part of the reason is that all those renames cause big
delete/create diffs. We *could* use git rename patches, but then you'd
have to apply them with "git apply" rather than the legacy "patch"
executables. But as it is, the patch is almost a third of the size of
the tar-ball, which makes me wonder if there's even any point to such
a big patch?

Apart from the re-organization, there is really just a lot of changes
all over. It's about 75% drivers (and that's without the renames
counted as big delete/create events - in the traditional diff, more
than 90% is drivers), 15% arch, and 10% "rest" (mainly fs and net -
with header file changes showing up in the statistics too).

What doesn't even show up in the stats is the VM changes, although
those may well be the most noticeable core stuff. It may be fairly
small, but it's rather more core, and has the potential to affect
everybody. People have been working on writeback tuning, and the whole
IO-less dirty balancing. So now foreground writeback should be a thing
of the past. Let's see how that all works out.

Have fun, give it a good testing. There shouldn't be anything hugely
scary in there, but there *is* a lot of stuff. The fact that 3.1
dragged out did mean that this ended up being one of the bigger merge
windows, but I'm not feeling *too* nervous about it.

                 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/

Powered by blists - more mailing lists