linux-kernel - Re: [PATCH -v2] Resource: fix region

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]

Message-ID: <Ztmo_EITDSRewSka@smile.fi.intel.com>
Date: Thu, 5 Sep 2024 15:50:04 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: David Hildenbrand <david@...hat.com>
Cc: Dan Williams <dan.j.williams@...el.com>,
	"Huang, Ying" <ying.huang@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linux-cxl@...r.kernel.org,
	Davidlohr Bueso <dave@...olabs.net>,
	Jonathan Cameron <jonathan.cameron@...wei.com>,
	Dave Jiang <dave.jiang@...el.com>,
	Alison Schofield <alison.schofield@...el.com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Ira Weiny <ira.weiny@...el.com>,
	Alistair Popple <apopple@...dia.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>, Baoquan He <bhe@...hat.com>
Subject: Re: [PATCH -v2] Resource: fix region_intersects() for CXL memory

On Thu, Sep 05, 2024 at 02:42:05PM +0200, David Hildenbrand wrote:
> 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@...ux.intel.com> 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.

Point is, that this is exceptional. And better to teach people based on better
practices, no?

> > > 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.

How is it better than having it in lore.kernel.org in archives where you even
see who _actually_ participated in discussion, if any?

Again, Cc neither in the Git commit, nor in the email guarantees the people
were involved. Having Cc in the commit just a big noise that pollutes it.
Especially I do not understand at all Cc: mailing-list@....bla.bla cases.
They are not people, they have a lot of archives besides lore.kernel.org,
only waste of resources in all means of that. I tried to summarize that in
the submitted patches to the documentation, that I referred earlier in this
thread to.

-- 
With Best Regards,
Andy Shevchenko