From: Doug Anderson <dianders@chromium.org>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Joe Perches <joe@perches.com>,
Rob Herring <robherring2@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Leon Romanovsky <leon@kernel.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
ksummit@lists.linux.dev, tools@linux.kernel.org,
Simon Glass <sjg@chromium.org>
Subject: Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches)
Date: Fri, 23 Apr 2021 07:52:30 -0700 [thread overview]
Message-ID: <CAD=FV=Xi6TL05M2bYKNgNB-ePY40CvonPzJYeMhXMPGgYKA5_Q@mail.gmail.com> (raw)
In-Reply-To: <20210423091320.4f2381b2@coco.lan>
Hi,
On Fri, Apr 23, 2021 at 12:13 AM Mauro Carvalho Chehab
<mchehab@kernel.org> wrote:
>
> Em Thu, 22 Apr 2021 23:46:31 -0700
> Joe Perches <joe@perches.com> escreveu:
>
> > On Fri, 2021-04-23 at 08:04 +0200, Mauro Carvalho Chehab wrote:
> > > 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.
> >
> > I have a very similar script
> >
> > A portion of a cc script I use tests whether cc'ing the cover letter
> > to all listed maintainers of a patch series creates a header of less
> > than 512 chars and if so cc's all relevant maintainers, otherwise it
> > just cc's the mailing lists.
> >
> > (Ingo didn't/doesn't want to receive any emails from me)
> >
> > $ cat ~/bin/remove_undesirable_emails.sh
> > grep -vPi "(?:\bIngo\s+Molnar\b)"
> >
> > $ cat ~/bin/cc.sh
> > #!/bin/bash
> >
> > opts="--nogit --nogit-fallback --norolestats"
> > maint_file=$(mktemp -t XXXXXXXX.cc)
> >
> > if [[ $(basename $1) =~ ^0000- ]] ; then
> > ./scripts/get_maintainer.pl $opts $(dirname $1)/* | \
> > ~/bin/remove_undesirable_emails.sh > $maint_file
> > count=$(wc -c $maint_file | cut -f1 -d" ")
> > if [[ $count -lt 512 ]] ; then
> > cat $maint_file
> > else
> > ./scripts/get_maintainer.pl -nom -nor $opts $(dirname $1)/* | \
> > ~/bin/remove_undesirable_emails.sh
> > fi
> >
> > ...
> >
>
> Heh, mine is a lot more complex than that ;-)
>
> It internally runs git format-patch, git send-email and get_maintainers.pl,
> and, when --cover or --annotate is used, it opens a window to allow
> editing the text. It has several options in order to tweak its behavior.
FWIW, I suppose I'll take this opportunity to point out "patman",
which is the tool I use for this. It lives in U-Boot but I (and
several others) also use it for Linux development. See
<https://source.denx.de/u-boot/u-boot/-/blob/master/tools/patman/README>.
I seem to remember at one point Olof criticizing it as making it too
easy to send big patch series (apologies if I remembered this wrong
Olof), which I actually took as a big praise for the tool. ;-)
At the moment, patman does this for Linux:
1. By default calls "get_maintainer" to (separately) add CCs to each
patch in the series. There has been talk about this not being the
default for Linux and by default CCing everyone on all patches (or at
least making an option for it).
2. By default CCs everyone on the cover letter.
3. Neatly handles version history and includes version history both in
the cover letter and each patch.
4. ...and a whole load of other cool things.
I know it's nearly impossible to get people to change their workflows,
but if you're open to it I definitely suggest giving it a try. Simon
Glass (the original author) is also quite receptive to improvements.
-Doug
next prev parent reply other threads:[~2021-04-23 14:52 UTC|newest]
Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
2021-04-21 18:46 ` Christian Borntraeger
2021-04-21 18:51 ` Alexey Dobriyan
2021-04-21 18:53 ` Christian Borntraeger
2021-04-21 19:06 ` Al Viro
2021-04-21 19:14 ` James Bottomley
2021-04-21 19:22 ` Steven Rostedt
2021-04-21 19:26 ` Kees Cook
2021-04-21 19:32 ` Roland Dreier
2021-04-21 19:55 ` Julia Lawall
2021-04-21 20:28 ` Stephen Hemminger
2021-04-21 20:37 ` Julia Lawall
2021-04-21 20:45 ` Steven Rostedt
2021-04-21 20:50 ` Julia Lawall
2021-04-21 21:03 ` Jiri Kosina
2021-04-21 21:37 ` James Morris
2021-04-22 7:34 ` Geert Uytterhoeven
2021-04-22 7:51 ` Mike Rapoport
2021-04-22 8:45 ` Christian Brauner
2021-04-22 15:27 ` Steven Rostedt
2021-04-22 9:39 ` Mauro Carvalho Chehab
2021-04-22 9:55 ` Mauro Carvalho Chehab
2021-04-22 12:01 ` Leon Romanovsky
2021-04-22 12:26 ` Mark Brown
2021-04-22 12:35 ` Leon Romanovsky
2021-04-22 12:52 ` Hans Verkuil
2021-04-22 13:33 ` Mauro Carvalho Chehab
2021-04-22 13:42 ` Leon Romanovsky
2021-04-22 12:18 ` Leon Romanovsky
2021-04-22 15:38 ` Shuah Khan
2021-04-23 9:06 ` Mauro Carvalho Chehab
2021-04-23 17:17 ` Leon Romanovsky
2021-04-23 22:41 ` Shuah Khan
2021-04-22 5:59 ` Christoph Hellwig
2021-04-22 6:28 ` Tomasz Figa
2021-04-22 7:05 ` Al Viro
2021-04-22 7:46 ` Al Viro
2021-04-22 7:06 ` H. Peter Anvin
2021-04-22 7:05 ` Jiri Kosina
2021-04-22 16:05 ` Roland Dreier
2021-04-22 16:24 ` Krzysztof Kozlowski
2021-04-22 18:03 ` Al Viro
2021-04-22 22:35 ` Thomas Gleixner
2021-04-22 22:53 ` Laurent Pinchart
2021-07-20 16:26 ` Kernel sustainability (was Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Daniel Vetter
2021-04-21 19:30 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Jiri Kosina
2021-04-21 20:28 ` Jiri Kosina
2021-04-21 22:18 ` Shuah Khan
2021-04-21 23:17 ` Guenter Roeck
2021-04-21 23:21 ` Shuah Khan
2021-04-21 19:47 ` Dan Carpenter
2021-04-22 9:34 ` Mauro Carvalho Chehab
2021-04-22 9:59 ` Johannes Berg
2021-04-22 10:52 ` Mauro Carvalho Chehab
2021-04-22 12:16 ` Mike Rapoport
2021-04-22 13:41 ` Mauro Carvalho Chehab
2021-04-22 20:15 ` Alexandre Belloni
2021-04-23 0:09 ` Randy Dunlap
2021-04-21 19:49 ` Alexandre Belloni
2021-04-22 2:05 ` Martin K. Petersen
2021-04-22 3:04 ` Joe Perches
2021-04-22 10:13 ` Mauro Carvalho Chehab
2021-04-22 12:07 ` Mark Brown
2021-04-22 16:42 ` Bart Van Assche
2021-04-22 17:58 ` Jiri Kosina
2021-04-22 4:21 ` Leon Romanovsky
2021-04-22 4:56 ` Al Viro
2021-04-22 5:52 ` Leon Romanovsky
2021-04-22 6:05 ` Christoph Hellwig
2021-04-22 6:03 ` Christoph Hellwig
2021-04-22 6:18 ` Leon Romanovsky
2021-04-22 9:20 ` Mauro Carvalho Chehab
2021-04-22 11:34 ` Leon Romanovsky
2021-04-22 13:22 ` Mark Brown
2021-04-22 13:47 ` Leon Romanovsky
2021-04-22 13:51 ` Mark Brown
2021-04-22 14:12 ` Mauro Carvalho Chehab
2021-04-22 14:51 ` Leon Romanovsky
2021-04-22 13:29 ` Steven Rostedt
2021-04-22 13:58 ` Leon Romanovsky
2021-04-22 14:20 ` Rob Herring
2021-04-23 6:04 ` Mauro Carvalho Chehab
2021-04-23 6:46 ` Joe Perches
2021-04-23 7:13 ` Mauro Carvalho Chehab
2021-04-23 7:20 ` [PATCH RFC] scripts: add a script for sending patches Mauro Carvalho Chehab
2021-04-23 7:20 ` Mauro Carvalho Chehab
2021-04-23 14:52 ` Doug Anderson [this message]
2021-04-23 16:03 ` Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Mark Brown
2021-04-23 17:12 ` Leon Romanovsky
2021-04-26 23:50 ` Simon Glass
2021-04-22 12:53 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
2021-04-22 13:08 ` Leon Romanovsky
2021-04-22 13:27 ` Konstantin Ryabitsev
2021-04-22 13:41 ` Leon Romanovsky
2021-04-22 16:28 ` Serge E. Hallyn
2021-04-22 17:56 ` Leon Romanovsky
2021-04-22 18:05 ` backfilling threads with b4 (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Konstantin Ryabitsev
2021-04-22 18:51 ` Leon Romanovsky
2021-04-25 10:58 ` Leon Romanovsky
2021-04-23 7:19 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Greg KH
2021-04-23 7:31 ` Christian Brauner
2021-04-23 18:50 ` Konstantin Ryabitsev
2021-04-22 12:40 ` Mark Brown
2021-04-22 12:54 ` Mike Rapoport
2021-04-22 13:23 ` Mark Brown
2021-04-22 15:19 ` Steven Rostedt
2021-04-22 21:19 ` Thomas Gleixner
2021-04-22 21:36 ` Steven Rostedt
2021-04-22 22:39 ` Thomas Gleixner
2021-04-23 0:26 ` Joe Perches
2021-04-23 6:15 ` Greg KH
2021-04-23 6:50 ` Dan Williams
2021-04-23 7:13 ` Geert Uytterhoeven
2021-04-23 14:41 ` Shuah Khan
2021-04-23 9:12 ` Michal Hocko
2021-04-22 14:51 ` Laurent Pinchart
2021-04-22 15:14 ` Mike Rapoport
2021-04-22 15:17 ` Laurent Pinchart
2021-04-22 15:35 ` Al Viro
2021-04-22 15:32 ` Shuah Khan
2021-04-22 10:35 ` Mauro Carvalho Chehab
2021-04-22 11:03 ` Sudip Mukherjee
2021-04-22 14:00 ` Steven Rostedt
2021-04-22 14:07 ` Jiri Kosina
2021-04-22 15:31 ` Sudip Mukherjee
2021-04-22 21:33 ` Thomas Gleixner
2021-04-22 20:28 ` Andrew Morton
2021-04-22 20:46 ` Steven Rostedt
2021-04-22 12:32 ` Martin K. Petersen
2021-04-22 15:11 ` Laurent Pinchart
2021-04-22 15:28 ` James Bottomley
2021-04-22 15:35 ` Johannes Berg
2021-04-22 15:36 ` Mark Brown
2021-04-22 15:40 ` James Bottomley
2021-04-23 9:27 ` Dan Carpenter
2021-04-22 13:24 ` Konstantin Ryabitsev
2021-04-22 14:31 ` Mauro Carvalho Chehab
2021-04-22 15:34 ` Shuah Khan
2021-04-22 15:42 ` James Bottomley
2021-04-22 15:48 ` James Bottomley
2021-04-22 15:52 ` Steven Rostedt
2021-04-22 16:08 ` Shuah Khan
2021-04-22 16:13 ` Jan Kara
2021-04-22 17:04 ` Steven Rostedt
2021-04-22 17:08 ` Martin K. Petersen
2021-04-23 11:16 ` Jan Kara
2021-04-23 12:57 ` Mauro Carvalho Chehab
2021-04-23 7:58 ` Mauro Carvalho Chehab
2021-04-23 10:54 ` Greg KH
2021-04-23 17:09 ` Leon Romanovsky
2021-04-22 16:23 ` Konstantin Ryabitsev
2021-04-22 16:38 ` Bart Van Assche
2021-04-22 16:57 ` Leon Romanovsky
2021-04-22 18:03 ` Jiri Kosina
2021-04-22 21:26 ` Thomas Gleixner
2021-04-22 21:36 ` Jiri Kosina
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='CAD=FV=Xi6TL05M2bYKNgNB-ePY40CvonPzJYeMhXMPGgYKA5_Q@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=joe@perches.com \
--cc=ksummit@lists.linux.dev \
--cc=leon@kernel.org \
--cc=mchehab@kernel.org \
--cc=robherring2@gmail.com \
--cc=rostedt@goodmis.org \
--cc=sjg@chromium.org \
--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.