On 4/1/22 22:40, Linus Torvalds wrote:
I've had enough with the big random kvm pull requests. NONE of this has been in linux-next before the merge window. In fact, None of it was there even the first week of the merge window. So by all means send me fixes. But no more of this last-minute development stuff, which clearly was not ready to go before the merge window started, and must have been some wild last-minute merging thing.
tl;dr okey dokey, will resend in a few minutes. But anyway here's a description of how I do things; there's certainly a lot of variability among subsystems, so perhaps it helps to share it.
All this stuff in general has been ready for a few weeks, even though it was not committed to linux-next. It was not committed because in general I prioritize big merges that affect existing code, as those need a lot more time in linux-next and absolutely go in the first pull request. These are the larger patch series with higher chance of introducing regressions, often nondeterministic ones with little possibility to bisect, and they take a lot of time for both reviewing and testing.
While I focus on the bigger stuff for the first pull request, others are busy sending and also reviewing smaller series. I start to grab around -rc6, though this time it was a bit later due to a larger first PR and due to the whole family being sick at the wrong time. But in general, things that spill into the second week of the merge window are usually:
* covered very well by the testsuites (today's pull request was 30% documentation and tests; those tests only cover new code and even more tests exist outside the selftests framework and outside the Linux tree).
* and/or only activated by userspace bits that only exist in developer trees, or sometimes do not exist at all outside Amazon/Google.
Very often, at the time this code is merged, there are zero chances that any linux-next tester ever hits the code except via selftests or static analysis; even syzkaller needs to be taught the new ioctls.
This is a workflow that I've been using for a few years. If that's not okay, I can certainly stop doing that and only send one pull request.
kvm needs to make stability as a priority.
We are, and this includes both selftests for new features and lots of eyes looking at older code. Some of that crappy code I can definitely blame on my own inexperience or overwork; I am happy that people go through it with a fine-toothed comb and I try to help as well (which takes away time from development, so you could say it also helps stability).
Of the stuff you see from me during -rc, merge-window bugs are relatively rare and merge-window regressions even less so. Instead you'll see a lot of new selftests, fixes to old bugs, cleaning up lockless code to removes nasty race conditions, etc. (one of these days I want to get some numbers to see if my intuition is correct, though).
Again, if you prefer this kind of work to go through the merge window because it's too large for -rc, that's fine by me. But overall, rest assured that when I send things late it's not to sneak them into a release; if anything, it's out of abundance of caution, and wanting to keep linux-next.git and linux.git as stable and bisectable as possible.
Thanks, Paolo
