I was really hoping that rc7 would be the last rc, but it appears that
reality is once against conspiring against my well-laid plans, and is
forcing me to do an rc8. It's not like there were a lot of changes,
but the last-minute dcache fixes in particular made it not really sane
to just make a final release without another week of testing.
Now, normally, an rc8 isn't really a big deal - 3.15 is one of the
biggest (if not _the_ biggest) releases in a long time, and we do
rc8's with some regularity. It may not be every release, but I think
it's about a fifty-fifty chance whether any particular release goes to
rc8. So I shouldn't be upset, and I'm certainly not surprised.
No, the real reason I was hoping that we wouldn't need to do an rc8
for 3.15 is that school is out in two weeks, and we're doing our
family vacation immediately after that. And I'd hate to have yet
another "Linus is traveling during the merge window" thing. Normally I
have been luckier with my trips than that.
Now, I'll have internet, and I *could* do the merge window while on
vacation with the family. I'd just prefer not to.
SO... Let's try something new. I suspect most people are ready to
start the merge window, and we could try how it would be to overlap
the first week of the merge window with the last week of the previous
release. Most of the submaintainers already use git branches
actively, so I doubt anybody will find it too confusing if I end up
having a "next" branch for a week that contains the stuff I pull for
3.16.
So let's try to see how well that works - the last weeks of the
release tends to be me just waiting around to make sure nothing bad is
happening, so doing this kind of overlapping development *should* work
fine. Maybe it works so well that we'll end up doing it in the future
even if there *isn't* some kind of scheduling conflict that makes me
want to start the merge window before I'm 100% comfortable doing the
release for the previous version.
And it's not like I think rc8 is in any way broken. I just don't feel
comfortable doing a real 3.15 release without a _bit_ more time for
people to use the fixed dentry code.
Anyway, apart from the dcache changes, there's a lot of random smaller
stuff. One one-liner in particular is interesting: Minchan Kim had a
load that basically ate up all the kernel stack on x86-64, and so this
finally does something I've been trying to delay for a long time - it
expands the stack to 16kB. I think all other 64-bit architectures have
done that a long time ago already, so it's not exactly shocking, but
it's a somewhat fundamental change on one of the main architectures.
Linus
