Linux 3.15-rc8 … and merge window for 3.16

I was really hoping that rc7 would be the last rc, but it appears thatreality is once against conspiring against my well-laid plans, and isforcing 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 saneto 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 thebiggest (if not _the_ biggest) releases in a long time, and we dorc8's with some regularity. It may not be every release, but I thinkit's about a fifty-fifty chance whether any particular release goes torc8. 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 rc8for 3.15 is that school is out in two weeks, and we're doing ourfamily vacation immediately after that. And I'd hate to have yetanother "Linus is traveling during the merge window" thing. Normally Ihave been luckier with my trips than that.Now, I'll have internet, and I *could* do the merge window while onvacation with the family. I'd just prefer not to.SO... Let's try something new. I suspect most people are ready tostart the merge window, and we could try how it would be to overlapthe first week of the merge window with the last week of the previousrelease.  Most of the submaintainers already use git branchesactively, so I doubt anybody will find it too confusing if I end uphaving a "next" branch for a week that contains the stuff I pull for3.16.So let's try to see how well that works - the last weeks of therelease tends to be me just waiting around to make sure nothing bad ishappening, so doing this kind of overlapping development *should* workfine. Maybe it works so well that we'll end up doing it in the futureeven if there *isn't* some kind of scheduling conflict that makes mewant to start the merge window before I'm 100% comfortable doing therelease for the previous version.And it's not like I think rc8 is in any way broken. I just don't feelcomfortable doing a real 3.15 release without a _bit_ more time forpeople to use the fixed dentry code.Anyway, apart from the dcache changes, there's a lot of random smallerstuff. One one-liner in particular is interesting: Minchan Kim had aload that basically ate up all the kernel stack on x86-64, and so thisfinally does something I've been trying to delay for a long time - itexpands the stack to 16kB. I think all other 64-bit architectures havedone that a long time ago already, so it's not exactly shocking, butit's a somewhat fundamental change on one of the main architectures.               Linus