From: Linus Torvalds <torvalds@linux-foundation.org>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Linux 2.6.31-rc1
Date: Wed, 24 Jun 2009 17:18:19 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0906241656030.3605@localhost.localdomain> (raw)
We've had the regular two-week (and one day) merge window, and -rc1 is
out, and the merge window is closed.
[ I suspect I'll still merge the SCore architecture, I wanted to give it a
quick peek, but I've been busy with all the other patches so I'm closing
the merge window now, but leaving myself the option of merging Score
later - last I looked, the only non-SCore file it touched was the
MAINTAINERS file, so it's not like it should break anything else ]
There's a lot in there, but let me say that as far as the whole merge
window has gone, I've seldom felt happier merging stuff from people. I'm
really hoping it isn't just a fluke, but people kept their git trees
clean, and while there were a couple of times that I said "no, I'm not
going to merge that", on the whole this was a really painless merge window
for me.
I'm not saying that it was necessarily less bug-free than usual, I'm just
saying that on the whole people sent me merge requests that made sense,
explained what they did, and when I pulled I saw clear development lines.
That just makes it much easier for me.
So thanks to everybody involved.
I hope that doesn't mean that it was really painful for others, or that
we'll be chasing down more bugs than usual. And I _really_ hope we can
keep things going this way, and it wasn't a one-off "things just happened
to work this time".
As to the actual changes - too many to list. As usual, the bulk of the
changes are to drivers (70% of the diffs), with drivers/staging being the
bulk of that (about 60% of all driver changes - 40% of the total). But
wonder of wonder, I think drivers/staging actually _shrank_ this time
around, alledgely due to cleanups. Believe that who will.
On the filesystem front, we had btrfs, ext3 and xfs getting active
development (Why xfs? Beats me, but that's what the stats say), and a fair
chunk of work on the whole fsnotify unification work. And the VFS layer
got some TLC wrt ACL and private namespace handling.
On architectures: ARM, powerpc, mips, sh, x86 are the bulk of it. On ARM,
the bulk is new platforms (u300, freescale stmp, whatever), there seems to
be no end to crazy new arm platforms. On x86 (and at least some degree on
powerpc), a noticeable part is the whole new perf-counter subsystem. Along
with lots and lots of other stuff.
On the whole? Tons of stuff. Let's start testign and stabilizing.
Linus
next reply other threads:[~2009-06-25 0:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-25 0:18 Linus Torvalds [this message]
2009-06-25 6:32 ` [PATCH] i2c: fix build bug in i2c-designware.c Ingo Molnar
2009-06-25 17:40 ` Ben Dooks
2009-06-25 17:49 ` Baruch Siach
2009-06-28 10:05 ` Linux 2.6.31-rc1 Pavel Machek
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=alpine.LFD.2.01.0906241656030.3605@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
/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
Powered by JetHome