All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <mripard@redhat.com>
To: Brian Masney <bmasney@redhat.com>
Cc: tools@linux.kernel.org
Subject: Re: Suggestion for b4 prep: new flag to collect email addresses on a per patch basis
Date: Tue, 2 Sep 2025 13:15:23 +0200	[thread overview]
Message-ID: <20250902-robust-adorable-dragonfly-d034ef@houat> (raw)
In-Reply-To: <aK9q1S_Xvzof7IiV@x1>

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

Hi,

On Wed, Aug 27, 2025 at 04:30:13PM -0400, Brian Masney wrote:
> Hi,
> 
> I recently had to send out this 114 patch series that covers changes to
> drivers/clk to migrate away from a deprecated API:
> 
> https://lore.kernel.org/linux-clk/20250811-clk-for-stephen-round-rate-v1-0-b3bf97b038dc@redhat.com/
> 
> 40 of these clk drivers have entry in the MAINTAINERS file, so
> 'b4 prep --auto-to-cc' adds everyone to the To line for the whole
> series. Most people only have 1 or 2 drivers that's relevant to them
> in the big series, so it creates a lot of noise for people.
> 
> For big series like this, what do you think about adding an option to
> 'b4 prep' to have it only put someone on the To line for the patch(es)
> of interest? So for example, let's say we have two patches that make
> changes to drivers/clk/driver1.c and drivers/clk/driver2.c.
> 
> - [PATCH 0/2] clk: some changes  # Sent out to everyone. Union of all
>                                  # email addresses below.
> - [PATCH 1/2] clk: driver1:      # Only sent to driver1 maintainers
> - [PATCH 2/2] clk: driver2:      # Only sent to driver2 maintainers
> 
> I could have sent out maybe 80 ish or so small patch series, but there's
> downsides to that as well for the maintainer.

I had to do a similar thing today, and ended up doing:

git rebase $BASE -i --exec 'git commit --no-edit --amend -F <(git show --no-patch --format=%B HEAD && echo "---" && git show HEAD | ./scripts/get_maintainer.pl --nogit --nogit-fallback --norolestats  --nol --nor | while read -r line; do echo "To: $line"; done && git show HEAD | ./scripts/get_maintainer.pl --nogit --nogit-fallback --norolestats --nom  | while read -r line; do echo "Cc: $line"; done)'

It's quite a mouthful, but it added the list of recipients for each patch after --- based on what get_maintainer retrieves.

Once that's done, b4 properly picks up on it.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

      reply	other threads:[~2025-09-02 11:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-27 20:30 Suggestion for b4 prep: new flag to collect email addresses on a per patch basis Brian Masney
2025-09-02 11:15 ` Maxime Ripard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250902-robust-adorable-dragonfly-d034ef@houat \
    --to=mripard@redhat.com \
    --cc=bmasney@redhat.com \
    --cc=tools@linux.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.