Re: [PATCH] serial/pmac_zilog: Remove flawed mitigation for rx irq flood

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Finn Thain <fthain@xxxxxxxxxxxxxx> writes:
On Fri, 5 Apr 2024, Michael Ellerman wrote:
---
(here is a good location for Cc:)

Documentation/process/submitting-patches.rst indicats that it should 
be above the "---" separator together with Acked-by etc. Has this 
convention changed recently?

The docs don't really say where to put the Cc: tags, although they are 
mentioned along with other tags which clearly are intended to go above 
the separator.

I see no ambiguity there. What's the point of copying the message headers 
into the message body unless it was intended that they form part of the 
commit log?

In many cases I think it's the reverse. The Cc headers are in the commit
log *so that* git-send-email will add them to the Cc list when the patch
is sent.

In that case they can sit below the separator and still function.

IMO there is no value in having them in the commit log. The fact that
someone was Cc'ed on a patch 10 years ago is not interesting. If it ever
was interesting, for some forensic purpose, the mail archives would be
the place to look anyway.

I see, I will prepare a patch to discuss this aspect.

FYI there was a discussion about this several years ago, where at least 
some maintainers agreed that Cc: tags don't add much value and are 
better placed below the --- separator.


Maintainers who merge patches almost always add tags. And they can use the 
Cc tags from the message headers if they wish to. Or they can omit them or 
remove them. I don't mind. And I'd be happy to resubmit the patch with 
different tags if that's what is needed by the workflow used by Jiri Slaby 
or Greg Kroah-Hartman.

Many maintainers won't drop Cc: tags if they are there in the submitted
patch. So I agree with Andy that we should encourage folks not to add
them in the first place.

But that's getting very off topic for your submission :)

cheers




[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux