So I did debate calling it 5.0, but if we all help each other, I'm sure we can count to 20. It's a nice round number, and I didn't want to 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 is over. This was a fairly big merge window, but it didn't break any records, just solid. And things look pretty regular, with about 70% of the 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 selftest changes, but also various perf tooling updates.
There's a vfs pull request I declined and it might still go in later in a slightly reduced form, but apart from that I think everything got merged. We had one pull request that almost missed the merge windows due to a silly change in my email setup, but I verified that nothing else had happened to hit that special case.
One thing I _would_ like to point out as the merge window closes: I tend to delay some pull requests that I want to take a closer look at until the second week of the merge window when things are calming down, and that _really_ means that I'd like to get all the normal pull requests in the first week of the two-week merge window. And most people really followed that, but by Wednesday this week I had gotten a big frustrated that I kept getting new pull requests when I wanted to really just spend most of the day looking through the ones that deserved 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 a more explicit rule that I will literally stop taking new pull requests some time during the second week unless you have a good reason for why it was delayed.
Because yes, the merge window is two weeks, but it's two weeks partly exactly _because_ people (not just me) sometimes need extra time to resolve any possible issues, not because regular everyday pull requests should spread out over the whole two weeks. The development for things meant for the next release should have been done by the time the merge window opens.
Anyway, let's see. Maybe it won't be needed. It hasn't become a problem, 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 that I must have missed acknowledging emails for a few pull requests. I'm hoping that by the time the next merge window rolls around, we'll just have new automation for it, so that everybody just automatically gets notified when their pull request hit mainline. In the meantime, you have 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 I pulled from with a one-liner "mergelog". Very much a high-level summary of merges, for details you need to look into the git tree..
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.