On Fri, 2024-02-02 at 16:15 +0000, Peter Maydell wrote: > On Fri, 2 Feb 2024 at 16:01, David Woodhouse <dw...@infradead.org> wrote: > > > > What is the next step? Post the full series as a v5, or perhaps just > > the single fixed patch which is now at > > https://git.infradead.org/?p=users/dwmw2/qemu.git;a=commitdiff;h=2c20b4ee96db > > > > ... and then another pull request? > > If that diff above is the only change, then: > * roll a new pullrequest with the fix squashed into the appropriate patch > * have the subject marker be "PULL v2" > * you can send just the cover-letter and the one patch that has changed, > you don't need to resend the entire series (though it's not a big > deal if you do send the whole set of mails again)
Done, thank you. > > The docs are fairly clear that pull > > requests can't have even minor changes that haven't been posted > > separately... and I guess the above incremental doesn't count? > > Which bit of the docs is that? It's not our actual practice, > so we should really fix the wording. The principle is "don't > stick code into pullreqs that hasn't been through the review > process", but in practice especially for submaintainers who > know the system it's not uncommon to say "I'm going to > squash change X in and take this" or similar rather than > forcing submitters to do another round of sending out patches. > There should be *something* on the list to say this change was > put in, but eg the exchange in this email thread is fine for that. I think I was looking at https://www.qemu.org/docs/master/devel/submitting-a-pull-request.html where it says "In particular if you’ve corrected issues in one round of code review, you need to send your fixed patch series as normal to the list; you can’t put it in a pull request until it’s gone through. (Extremely trivial fixes may be OK to just fix in passing, but if in doubt err on the side of not.)" I think the doc is actually fine and I was just reading it too conservatively. I have been making a conscious effort to pay attention, follow the process and fit in, rather than just turning up and doing whatever comes naturally from decades of working on open source. (I do not *promise* that will last.)
smime.p7s
Description: S/MIME cryptographic signature
