linux-kernel - Re: [PATCH] perf/tests: Fix tests 84 and 86 Add --metric-only on s390

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] [day] [month] [year] [list]

Message-ID: <aAp53m7fwmkOoSrz@x1>
Date: Thu, 24 Apr 2025 14:50:22 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Thomas Richter <tmricht@...ux.ibm.com>, Ingo Molnar <mingo@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
	linux-perf-users@...r.kernel.org, namhyung@...nel.org,
	agordeev@...ux.ibm.com, gor@...ux.ibm.com, sumanthk@...ux.ibm.com,
	hca@...ux.ibm.com
Subject: Re: [PATCH] perf/tests: Fix tests 84 and 86 Add --metric-only on s390

On Thu, Apr 24, 2025 at 03:33:10PM +0200, Thomas Richter wrote:
> Fixes: 45a86d017adf ("perf test: Add --metric-only to perf stat output tests")
> Signed-off-by: Thomas Richter <tmricht@...ux.ibm.com>
> Suggested-by: Sumanth Korikkar <sumanthk@...ux.ibm.com>
> Suggested-by: Heiko Carstens <hca@...ux.ibm.com>
> Reviewed-by: Sumanth Korikkar <sumanthk@...ux.ibm.com>
> Cc: Namhyung Kim <namhyung@...nel.org>

Thanks, applied to perf-tools-next.

But please try to look at how patches are applied, specifically in how
commit log messages are rewritten, what is modified in the commit log
messages.

Specifically: When we do a 'git log --oneline' what we see should help
we find whatever we're trying to find. Twitter (not-X) style.

While I agree with Namhyung that whatever reduces the work a maintainer
should (have to) care about, and doing this is just some muscle memory
from sending patches to Ingo, I do think that trying to be consistent on
how we describe the problem, how the solution being proposed fixes the
problem, and then, when that is read, and the code is read, all matches,
bingo, patch accepted, tests pass, lets focus on the next issue.

This is not something aimed at you, but its something that takes time
when I'm processing patches, maybe I should just ignore this if the code
is good enough (I do this more than I want), but I think getting this
out of my mind is important.

Lowering the bar invites more people to contribute, but then it bites us
later.

- Arnaldo