Re: [PATCH net v4 0/7] net: dsa: mt7530: fix multiple CPU ports, BPDU and LLDP handling

[Andrew Lunn]

On Mon, Jun 12, 2023 at 09:52:29PM +0100, Russell King (Oracle) wrote:
> On Mon, Jun 12, 2023 at 12:37:29PM +0100, Russell King (Oracle) wrote:
> > Hi,
> > 
> > Please slow down your rate of patch submission - I haven't had a chance
> > to review the other patches yet (and I suspect no one else has.) Always
> > allow a bit of time for discussion.
> > 
> > Just because you receive one comment doesn't mean you need to rush to
> > get a new series out. Give it at least a few days because there may be
> > further discussion of the points raised.
> > 
> > Sending new versions quickly after previous comments significantly
> > increases reviewer workload.
> 
> And a very illustratory point is that I responded with a follow up to
> your reply on v2, hadn't noticed that you'd sent v4, and the comments
> I subsequently made on v2 apply to v4... and I haven't even looked at
> v3 yet.

Hi Arınç

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#netdev-faq

says:

  don't repost your patches within one 24h period

  2.6.6. Resending after review¶

  Allow at least 24 hours to pass between postings. This will ensure
  reviewers from all geographical locations have a chance to chime
  in. Do not wait too long (weeks) between postings either as it will
  make it harder for reviewers to recall all the context.
 
  Make sure you address all the feedback in your new posting. Do not
  post a new version of the code if the discussion about the previous
  version is still ongoing, unless directly instructed by a reviewer.

During a weekend, i would say 24 hours is way too short, and 3 days is
more like it, given that for a lot of people being a Maintainer is a
day job, 9-5 week days.

You should also try to gauge how fast Maintainers are reacting. 24
hours is often too fast. You know Russell is interested in these
patches, so don't send a new version until you actually get feedback
from him, and the discussion has come to a conclusion.

     Andrew