Linux Today: Linux News On Internet Time.
Search Linux Today
Linux News Sections:  Developer -  High Performance -  Infrastructure -  IT Management -  Security -  Storage -
Linux Today Navigation
LT Home
Contribute
Contribute
Link to Us
Linux Jobs


More on LinuxToday


Linux 3.2 rc1

Nov 08, 2011, 16:00 (0 Talkback[s])

"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

Complete Story

Related Stories: