Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches

[Mauro Carvalho Chehab <mchehab@kernel.org>]

Em Thu, 22 Apr 2021 09:20:19 -0500
Rob Herring <robherring2@gmail.com> escreveu:

> On Thu, Apr 22, 2021 at 8:30 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Thu, 22 Apr 2021 14:34:53 +0300
> > Leon Romanovsky <leon@kernel.org> wrote:
> >  
> > > > This is not a matter of bad practice. There are a couple of reasons
> > > > why each patch on a series will have a different group of Cc, like:
> > > >
> > > >     - driver maintainers for each patch may be different;
> > > >     - scripts/get_maintainers.pl will return a different Cc/To;
> > > >     - patch series touch different subsystems;  
> > >
> > > Like Christoph said, if it is unrelated send the patches as separated
> > > series.  
> >
> > Since I use quilt to send my patches, my only two choices are all patches,
> > or individual ones with Cc. Some of my patches will need to touch every
> > architecture. I'll Cc the maintainers of the architecture code, but not
> > include them in every architecture patch. And because this code depends on
> > other patches, I can not send them as individual series.
> >
> > I use to have issues with this, but now with lore, I can trivially find the
> > entire thread and read it the whole story. IMO, it is no longer bad
> > practice to Cc only a single patch is a larger series to a maintainer, for
> > the one patch that touches their code. It's a "FYI, I'm touching your
> > code". But because of lore, it's really easy for them to get the full
> > picture.
> >
> > I much rather have my INBOX today be only patches that touches my code,
> > then full series of patches that I really don't care about. Worse yet, I'll
> > get Cc'd on a full series of 20 patches, where only one patch touches my
> > code. The sad part is, I'm much more likely to ignore that series, because
> > I'm added to stuff by get-maintainers for the strangest reason, and
> > completely miss that there's a single patch in there that really requires
> > my review.
> >
> > Please, just Cc me on code that touches something I maintain or listed as
> > a reviewer (which is still a lot).  
> 
> Unless the process of who to Cc or not is completely automated,
> relying on submitters to do the right thing to give you the subset of
> emails you want to see is never going to work. I have frequent
> problems with folks not Cc'ing the DT list for DT patches, how hard is
> that? I think the answer is making where patches are sent less
> important and better/easier filtering from lore (which is coming).

I have a script to automate it, but I had to tweak it while handling
patches that cross a single subsystem boundaries, using git send-email
with the c/c list obtained from get_maintainers.pl.

By default, the script adds all maintainers, reviewers and all mailing
lists to the cover letter, but that sometimes generate a cover letter
with 80+ c/c, which will be automatically rejected by anti-spam
measures and by mail servers.

So, I played with two different alternatives:

1. At the beginning, I changed the script to c/c only the mailing lists,
   excluding maintainers/reviewers;
2. As the feedback was not great, I changed the script to c/c only
   the maintainers, excluding mailing lists/reviewers. It seems that
   this worked better.

I didn't try to play with bcc, as replying to it would not send
the replies to everyone.

If you think it is worth, I could submit it to scripts/, but I
suspect we may need to adjust it to work with all maintainers'
workflows.

Thanks,
Mauro