From: Lukas Bulwahn <email@example.com>
To: Dwaipayan Ray <firstname.lastname@example.org>
Subject: Re: [Linux-kernel-mentees] checkpatch.pl investigation: NO_AUTHOR_SIGN_OFF issues
Date: Fri, 25 Sep 2020 09:20:00 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.2009250854230.5992@felia> (raw)
[-- Attachment #1: Type: text/plain, Size: 2883 bytes --]
On Fri, 25 Sep 2020, Dwaipayan Ray wrote:
> As Joe mentioned earlier, there might be four new
> warnings to handle better:
> 1) Same name, different address
> 2) Same address, different name
> 3) email extensions present in header but
> not in signed off by
> 4) comment blocks after name
> I am thinking to solve the first three in a single patch.
> As for the email extensions part, should it be handled
> differently? There will be redundant calls to that
> though because it's not an error seen quite often.
Dwaipayan, thanks for this initial structuring.
Let us try to put some systematic structure into this handling of the
There are basically two aspects to consider:
- which classes are potential mismatches can we potentially observe?
- which level of severity do we assign to each class of mismatch?
To the first point, you started with some initial classes above.
0) same name, same address (no mismatch)
1) same name, different address
subclasses: (how 'different' address?)
- email address differ by valid difference, e.g., extensions that
will go to the same inbox, e.g., the xyz+fds extension in mail
addresses. (that is your class 3, right?)
- two email addresses that are known to belong to the same individual
- known because of .mailmap
- known otherwise?
2) different name, same address
subclasses: (how 'different' name?)
- Firstname, Lastname (but middle-name initials differ)
- special "regional" characters, like ü vs. ue, etc.
- firstname and lastname are reverted etc.
3) different name, different address (but still we believe it "matches")
combinations of subclasses of 1) and 2), which we want to consider.
Then, to the second question:
So, these different classes we can think of and "assign" different
severities that checkpatch.pl can use.
Checkpatch.pl already has four levels:
three severity reporting levels: ERROR, WARN, CHECK, and
the level _do not report_ (which is implemented by just ignoring some kind
I think a lot of discussion will be around what severity to assign to
which class above, and in some way, long-term maintainers have a larger
say than we do here.
So, let us first modify checkpatch.pl to identify the various classes
above, maybe just starting very basic, with different name, same address
and same name, different address and run it over the commit range and see
which examples show up and how often.
For now, we first just use checkpatch.pl to identify the different types
and refine them into subclasses; then, we can discuss with severity should
be assigned to which type of mismatch.
The second question should not invalidate our data collection and
identification of subclasses, though.
Does that help? What do you think?
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
Linux-kernel-mentees mailing list
next prev parent reply other threads:[~2020-09-25 7:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 10:06 [Linux-kernel-mentees] checkpatch.pl investigation: NO_AUTHOR_SIGN_OFF issues Lukas Bulwahn
2020-09-18 10:29 ` Dwaipayan Ray
2020-09-18 10:44 ` Lukas Bulwahn
2020-09-21 9:07 ` Dwaipayan Ray
2020-09-21 9:12 ` Lukas Bulwahn
2020-09-21 9:15 ` Lukas Bulwahn
2020-09-22 13:21 ` Dwaipayan Ray
2020-09-22 18:38 ` Lukas Bulwahn
2020-09-22 19:08 ` Dwaipayan Ray
2020-09-23 7:32 ` Lukas Bulwahn
2020-09-23 7:38 ` Dwaipayan Ray
2020-09-23 7:42 ` Lukas Bulwahn
2020-09-25 4:18 ` Dwaipayan Ray
2020-09-25 7:20 ` Lukas Bulwahn [this message]
2020-09-25 7:29 ` Dwaipayan Ray
2020-09-25 7:35 ` Lukas Bulwahn
2020-09-26 11:31 ` Dwaipayan Ray
2020-09-28 13:30 ` Dwaipayan Ray
2020-09-28 14:09 ` Lukas Bulwahn
2020-09-28 14:20 ` Dwaipayan Ray
2020-09-28 15:09 ` Lukas Bulwahn
2020-09-28 15:06 ` Lukas Bulwahn
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).