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.