On 18/09/2023 18:12, Sean Christopherson wrote: [snip]
Tag them RFC, explain your expectations, goals, and intent in the cover letter, don't copy+paste cover letters verbatim between versions, and summarize the RFC(s) when you get to a point where you're ready for others to jump in. The cover letter is *identical* from v1=>v2=>v3, how is anyone supposed to understand what on earth is going on unless they happened to be in the same room as ya'll on Friday?
The cover letter is indeed identical because the purpose of the series has not changed. Each individual patch has a commit comment summarizing what changed from version to version or whether it is new in a perticular version. I thought this would be enough for any reviewer to be able to see what is going on. In future I will also roll these up into the cover letter.
Doing rapid-fire, early review on beta-quality patches is totally fine, so long as it's clear that others can effectively ignore the early versions unless they are deeply interested or whatever. A disclaimer at the top of the cover letter, e.g. This series is a first attempt at an idea David had to improve performance of the pfncache when KVM is emulating Xen. David and I are still working out the details, it's probably not necessary for other folks to review this right now. along with a summary of previous version and a transition from RFC => non-RFC makes it clear when I and others are expected to get involved. In other words, use tags and the cover letter to communicate, don't just view the cover letter as a necessary evil to get people to care about your patches.
That was not the intention at all; I put all the detailed explanation in the commit comments because I thought that would make review *easier*.
Paul
