linux-kernel - Re: [PATCH v1 2/2] Documentation: process: Recommend to put Cc: tags after cutter '---' line

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 23 Apr 2024 08:13:37 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: workflows@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v1 2/2] Documentation: process: Recommend to put Cc: tags
 after cutter '---' line

On Tue, Apr 23, 2024 at 04:19:38PM +0300, Andy Shevchenko wrote:
> The recommendation is based on the following rationale:
> 
> - it makes the commit messages much cleaner and easy to read, especially
>   on the screens of the mobile devices;

Reading commits on a mobile device is not what kernel development is
optimized for, sorry.

> - it reduces resources (memory, time, energy) to retrieve all these
>   headers, which are barely needed by a mere user, as for automation
>   they will be still available via mail archives, such as
>   https://lore.kernel.org, assuming the Link: or Message-ID tag is
>   provided.
> 
> Let's be environment friendly and save the planet!
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> ---
>  Documentation/process/5.Posting.rst          | 4 ++++
>  Documentation/process/submitting-patches.rst | 5 +++++
>  2 files changed, 9 insertions(+)

This breaks my existing workflow, sorry.  I can't track cc: below the
--- line because obviously, git cuts that off.  So I put them above
where git send-email can see them, AND where git can handle them when I
rebase/revise/etc.

Also, as Jon points out, the "environmental" argument seems very odd,
it's not like bits cost more to send around (they keep getting cheaper
in power and money), and processing power is pretty constant for servers
handling email, so I don't understand the power consumption argument.
Without some sort of data to back that up, I'd be loath to repeat it.

thanks,

greg k-h