archive mirror
 help / color / mirror / Atom feed
From: Lukas Bulwahn <>
To: Dwaipayan Ray <>
Subject: Re: [Linux-kernel-mentees] 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)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2883 bytes --]

On Fri, 25 Sep 2020, Dwaipayan Ray wrote:

> Hi,
> 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?)
     - examples:
       - 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 can use. 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 
of difference).

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

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

Reply instructions:

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 \
    --in-reply-to=alpine.DEB.2.21.2009250854230.5992@felia \ \ \ \

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