[U-Boot] [PATCH v2] patman: add option for limiting the Cc list

Many mailing-lists consider a long Cc list a sign of spam and will either drop the message or mark it for moderation. Because patman automatically invokes get_maintainer.pl the Cc list can expand unexpectedly. Allow the user to specify a limit for the Cc list.
This limit is applied after removing any known bouncing addresses. By default no limit is applied.
Signed-off-by: Chris Packham judge.packham@gmail.com --- I've fallen foul of the u-boot ML Cc limit a few times recently. I'm not sure what the actual limit is so I've left patman's default behaviour unlimited.
Changes in v2: - make default None to allow limit 0 to suppress the list completely
tools/patman/patman.py | 4 +++- tools/patman/series.py | 5 ++++- 2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/patman/patman.py b/tools/patman/patman.py index 8d2c78235a7e..e01510df9c0f 100755 --- a/tools/patman/patman.py +++ b/tools/patman/patman.py @@ -38,6 +38,8 @@ parser.add_option('-i', '--ignore-errors', action='store_true', parser.add_option('-m', '--no-maintainers', action='store_false', dest='add_maintainers', default=True, help="Don't cc the file maintainers automatically") +parser.add_option('-l', '--limit-cc', dest='limit', type='int', + default=None, help='Limit the cc list to LIMIT entries [default: %default]') parser.add_option('-n', '--dry-run', action='store_true', dest='dry_run', default=False, help="Do a dry run (create but don't email patches)") parser.add_option('-p', '--project', default=project.DetectProject(), @@ -157,7 +159,7 @@ else:
cc_file = series.MakeCcFile(options.process_tags, cover_fname, not options.ignore_bad_tags, - options.add_maintainers) + options.add_maintainers, options.limit)
# Email the patches out (giving the user time to check / cancel) cmd = '' diff --git a/tools/patman/series.py b/tools/patman/series.py index d526d4ee91d3..2735afaf88fe 100644 --- a/tools/patman/series.py +++ b/tools/patman/series.py @@ -202,7 +202,7 @@ class Series(dict): print(col.Color(col.RED, str))
def MakeCcFile(self, process_tags, cover_fname, raise_on_error, - add_maintainers): + add_maintainers, limit): """Make a cc file for us to use for per-commit Cc automation
Also stores in self._generated_cc to make ShowActions() faster. @@ -215,6 +215,7 @@ class Series(dict): add_maintainers: Either: True/False to call the get_maintainers to CC maintainers List of maintainers to include (for testing) + limit: Limit the length of the Cc list Return: Filename of temp file created """ @@ -238,6 +239,8 @@ class Series(dict): print(col.Color(col.YELLOW, 'Skipping "%s"' % x)) cc = set(cc) - set(settings.bounces) cc = [m.encode('utf-8') if type(m) != str else m for m in cc] + if limit is not None: + cc = cc[:limit] all_ccs += cc print(commit.patch, ', '.join(set(cc)), file=fd) self._generated_cc[commit.patch] = cc

On 27 May 2018 at 03:52, Chris Packham judge.packham@gmail.com wrote:
Many mailing-lists consider a long Cc list a sign of spam and will either drop the message or mark it for moderation. Because patman automatically invokes get_maintainer.pl the Cc list can expand unexpectedly. Allow the user to specify a limit for the Cc list.
This limit is applied after removing any known bouncing addresses. By default no limit is applied.
Signed-off-by: Chris Packham judge.packham@gmail.com
I've fallen foul of the u-boot ML Cc limit a few times recently. I'm not sure what the actual limit is so I've left patman's default behaviour unlimited.
Changes in v2:
- make default None to allow limit 0 to suppress the list completely
tools/patman/patman.py | 4 +++- tools/patman/series.py | 5 ++++- 2 files changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

Hi Chris,
On 27 May 2018 at 17:45, Simon Glass sjg@chromium.org wrote:
On 27 May 2018 at 03:52, Chris Packham judge.packham@gmail.com wrote:
Many mailing-lists consider a long Cc list a sign of spam and will either drop the message or mark it for moderation. Because patman automatically invokes get_maintainer.pl the Cc list can expand unexpectedly. Allow the user to specify a limit for the Cc list.
This limit is applied after removing any known bouncing addresses. By default no limit is applied.
Signed-off-by: Chris Packham judge.packham@gmail.com
I've fallen foul of the u-boot ML Cc limit a few times recently. I'm not sure what the actual limit is so I've left patman's default behaviour unlimited.
Changes in v2:
- make default None to allow limit 0 to suppress the list completely
tools/patman/patman.py | 4 +++- tools/patman/series.py | 5 ++++- 2 files changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Unfortunately this breaks the patman tests (patman -t). Can you please take a look?
Regards, Simon

On Thu, Jun 7, 2018 at 12:47 PM Simon Glass sjg@chromium.org wrote:
Hi Chris,
On 27 May 2018 at 17:45, Simon Glass sjg@chromium.org wrote:
On 27 May 2018 at 03:52, Chris Packham judge.packham@gmail.com wrote:
Many mailing-lists consider a long Cc list a sign of spam and will either drop the message or mark it for moderation. Because patman automatically invokes get_maintainer.pl the Cc list can expand unexpectedly. Allow the user to specify a limit for the Cc list.
This limit is applied after removing any known bouncing addresses. By default no limit is applied.
Signed-off-by: Chris Packham judge.packham@gmail.com
I've fallen foul of the u-boot ML Cc limit a few times recently. I'm not sure what the actual limit is so I've left patman's default behaviour unlimited.
Changes in v2:
- make default None to allow limit 0 to suppress the list completely
tools/patman/patman.py | 4 +++- tools/patman/series.py | 5 ++++- 2 files changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Unfortunately this breaks the patman tests (patman -t). Can you please take a look?
Regards, Simon
Ok, I'll take a look.
participants (2)
-
Chris Packham
-
Simon Glass