Message-ID: <30ffdecc-6ecd-5194-14ec-40e8b818889a@redhat.com>
Date:   Fri, 1 Apr 2022 23:59:40 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        KVM list <kvm@...r.kernel.org>
Subject: Re: [GIT PULL] Second batch of KVM changes for Linux 5.18

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

Powered by blists - more mailing lists