Linux 4.20 rc1

So I did debate calling it 5.0, but if we all help each other, I'msure we can count to 20. It's a nice round number, and I didn't wantto make a pattern of it. I think 5.0 happens next year, because then I*really* run out of fingers and toes.Anyway, 4.20-rc1 is tagged and pushed out, and the merge window isover. This was a fairly big merge window, but it didn't break anyrecords, just solid. And things look pretty regular, with about 70% ofthe patch is driver updates (gpu drivers are looming large as usual,but there's changes all over). The rest is arch updates (x86, arm64,arm, powerpc and the new C-SKY architecture), header files,networking, core mm and kernel, and tooling.In fact, tooling is quite noticeable. A fair amount of selftestchanges, but also various perf tooling updates.There's a vfs pull request I declined and it might still go in laterin a slightly reduced form, but apart from that I think everything gotmerged. We had one pull request that almost missed the merge windowsdue to a silly change in my email setup, but I verified that nothingelse had happened to hit that special case.One thing I _would_ like to point out as the merge window closes: Itend to delay some pull requests that I want to take a closer look atuntil the second week of the merge window when things are calmingdown, and that _really_ means that I'd like to get all the normal pullrequests in the first week of the two-week merge window. And mostpeople really followed that, but by Wednesday this week I had gotten abig frustrated that I kept getting new pull requests when I wanted toreally just spend most of the day looking through the ones thatdeserved a bit of extra attention.And yes, people generally kind of know about this and I really do get*most* pull requests early. But I'm considering trying to make that amore explicit rule that I will literally stop taking new pull requestssome time during the second week unless you have a good reason for whyit was delayed.Because yes, the merge window is two weeks, but it's two weeks partlyexactly _because_ people (not just me) sometimes need extra time toresolve any possible issues, not because regular everyday pullrequests should spread out over the whole two weeks. The developmentfor things meant for the next release should have been done by thetime the merge window opens.Anyway, let's see. Maybe it won't be needed. It hasn't become aproblem, it just was starting to feel a bit tight there.Oh, and I did try to do the reply emails. And I'm _entirely_ sure thatI must have missed acknowledging emails for a few pull requests. I'mhoping that by the time the next merge window rolls around, we'll justhave new automation for it, so that everybody just automatically getsnotified when their pull request hit mainline. In the meantime, youhave a good chance - but not a guarantee - that I'll send a "Pulled"ack email when I start processing a pull request.And as usual for rc1, the log below is just the list of people Ipulled from with a one-liner "mergelog". Very much a high-levelsummary of merges, for details you need to look into the git tree..                    Linus