Re: [PATCH -v2] Resource: fix region_intersects() for CXL memory

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

 



On 05.09.24 14:36, Andy Shevchenko wrote:
On Thu, Sep 05, 2024 at 01:08:35PM +0200, David Hildenbrand wrote:
On 05.09.24 12:56, Andy Shevchenko wrote:
On Wed, Sep 04, 2024 at 04:58:20PM -0700, Dan Williams wrote:
Huang, Ying wrote:
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> writes:

[..]

You may move Cc list after '---', so it won't unnecessarily pollute the commit
message.

Emm... It appears that it's a common practice to include "Cc" in the
commit log.

Yes, just ignore this feedback, it goes against common practice. Cc list
as is looks sane to me.

It seems nobody can give technical arguments why it's better than just keeping
them outside of the commit message. Mantra "common practice" nowadays is
questionable.

Just look at how patches look like in the git tree that Andrew picks up.
(IIRC, he adds a bunch of CCs himself that are not even part of the original
patch).

I know that and it's historical, he has a lot of the scripts that work and when
he moved to the Git it was another long story. Now you even can see how he uses
Git in his quilt approach. So, it's an exceptional and not usual workflow, hence
bad example. Try again :-)

Point is, it doesn't matter what we do in this patch here if Andrew will unify it at all.


Having in the git tree who was actually involved/CCed can be quite valuable.
More helpful than get_maintainers.pl sometimes.

First of all, there is no guarantee they _were_ involved. From this perspective
having Link: tag instead has much more value and supports my side of arguments.

Link is certainly preferable. Usually when I fix a commit, I make sure to CC the people that are listed for the patch, because it at least should have ended up in their mailbox.

Often, it also helped to see if a buggy commit was at least CCed to the right persons without digging through mailing list archives.

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux