archive mirror
 help / color / mirror / Atom feed
From: Dwaipayan Ray <>
To: Lukas Bulwahn <>
Subject: Re: [Linux-kernel-mentees] Linux kernel mentorship
Date: Tue, 15 Sep 2020 18:34:15 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <alpine.DEB.2.21.2009142016150.6496@felia>

[-- Attachment #1.1: Type: text/plain, Size: 2495 bytes --]

Sorry for the late reply.

> First explain:
> - which situations does currently complain about?
Currently, checkpatch complains whenever the author mail is not
found in any signed-off-by block in the patch.

> - for which situation do you want to have more refined checks?
The situations where author might have signed off using a different
email. I believe multiple mail addresses isn't uncommon.

> - why does that actually improve

It shall significantly reduce the number of author_sign_off warnings. I have
not yet created a statistical count, but looking at the data I found several
such instances. This is certainly a false positive due to a condition which
checkpatch was not programmed to handle.
The avoidance of warnings on such known cases might also save the
committer and the maintainers some time.

> should complain when developers do something wrong.
> To really understand what is wrong behavior and what is not, you probably
> need to create some statistics on who authors and signs off with which
> names and email addresses.
> Maybe we can collect all the previous instances where we know that
> frequent developers, e.g., with more >100 commits, use multiple email
> addresses interchangeably. If we add that list to the repository and
> let others know how to maintain it, can make use of that.
> With that extended check, we can warn newbies that just have a broken git
> and sign-off setup and still reduce the false positives for the
> experienced developers that might just have good reasons to have the
> setup they have, i.e., they have this setup for many years and want to
> keep it that way.

This seems like a great idea. I can load the mailmap data into checkpatch
and form some kind of map between names and mail addresses.
If two mail addresses belong to same user then the warning can be ignored

I know that the kernel community is strict about such changes. So will this
acceptible? I can generate a proof of concept patch with the data at hand
if it seems like a good thing to work on.

> You can try to work that through or look for another case of potential
> improvement in your evaluation data.

I haven't found anything substantial yet. I will continue looking.
Earlier, you had told if I would like to take the task from Ayush to
fix checkpatch with git ranges. I would like to know about the task
and take it up if possible.


[-- Attachment #1.2: Type: text/html, Size: 4841 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

Linux-kernel-mentees mailing list

  reply	other threads:[~2020-09-15 13:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <alpine.DEB.2.21.2009110925160.9220@felia>
2020-09-12  9:09   ` [Linux-kernel-mentees] Linux kernel mentorship Dwaipayan Ray
2020-09-12 11:03     ` Lukas Bulwahn
2020-09-12 12:08       ` Dwaipayan Ray
2020-09-12 12:21         ` Lukas Bulwahn
2020-09-13  8:16           ` Dwaipayan Ray
2020-09-13 11:05             ` Lukas Bulwahn
     [not found]               ` <>
     [not found]                 ` <alpine.DEB.2.21.2009132015570.6806@felia>
2020-09-13 18:23                   ` Dwaipayan Ray
     [not found]                 ` <alpine.DEB.2.21.2009132010300.6806@felia>
2020-09-13 18:39                   ` Dwaipayan Ray
2020-09-14  5:17                     ` Lukas Bulwahn
2020-09-14 12:31                       ` Dwaipayan Ray
2020-09-14 13:49                         ` Lukas Bulwahn
2020-09-14 15:39                           ` Dwaipayan Ray
2020-09-14 18:32                             ` Lukas Bulwahn
2020-09-15 13:04                               ` Dwaipayan Ray [this message]
2020-09-16  7:01                                 ` Lukas Bulwahn
2020-09-17 13:09                                   ` Dwaipayan Ray
2020-09-17 13:41                                     ` Dwaipayan Ray
2020-09-17 14:18                                       ` Lukas Bulwahn
2020-09-17 14:43                                         ` Dwaipayan Ray
2020-09-17 15:03                                           ` Lukas Bulwahn
2020-09-17 14:13                                     ` 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='' \ \ \ \

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