Re: [PATCH v3 2/2] Documentation/process: Add a maintainer handbook for KVM x86

[Sean Christopherson]

On Wed, Apr 12, 2023, Kai Huang wrote:
> On Tue, 2023-04-11 at 10:16 -0700, Sean Christopherson wrote:
> > +Timeline
> > +~~~~~~~~
> > +Submissions are typically reviewed and applied in FIFO order, with some wiggle
> > +room for the size of a series, patches that are "cache hot", etc.� Fixes,
> > +especially for the current release and or stable trees, get to jump the queue.
> > +Patches that will be taken through a non-KVM tree (most often through the tip
> > +tree) and/or have other acks/reviews also jump the queue to some extent.
> > +
> > +Note, the vast majority of review is done between rc1 and rc6, give or take.
> > +The period between rc6 and the next rc1 is used to catch up on other tasks,
> > +i.e. radio silence during this period isn't unusual.
> > +
> > +Pings to get a status update are welcome, but keep in mind the timing of the
> > +current release cycle and have realistic expectations.� If you are pinging for
> > +acceptance, i.e. not just for feedback or an update, please do everything you
> > +can, within reason, to ensure that your patches are ready to be merged!� Pings
> > +on series that break the build or fail tests lead to unhappy maintainers!
> > +
> 
> It seems you don't like resending patch as a ping:
> 
> https://lore.kernel.org/lkml/20230410031021.4145297-1-alexjlzheng@xxxxxxxxxxx/t/#md30aa77e5c2592b5b1fb0401d14e6fdbf52c2e06
> 
> Do you want to include this to the documentation too?

Honestly, I would rather get Documentation/process/submitting-patches.rst updated
to rework its recommended use of RESEND.  I doubt I am the only person that thinks
a RESEND after 1-2 weeks to ping for reviews is inefficient and confusing for
everyone involved.  And on the flip side, AFAICT there's no mention anywhere of
the much more common (and IMO justified) use cases, e.g. to fix/tweak the To/Cc
lists or because there was an issue with mail delivery.