From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
To: Ayush <ayush@disroot.org>
Cc: linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [Linux-kernel-mentees] Regarding "Linux Kernel: Evaluate and Improve checkpatch.pl"
Date: Thu, 27 Aug 2020 07:28:56 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.2008270707440.9436@felia> (raw)
In-Reply-To: <32595de077ee7d674a628df11c58152f@disroot.org>
On Mon, 24 Aug 2020, Ayush wrote:
> August 22, 2020 1:36 PM, "Lukas Bulwahn" <lukas.bulwahn@gmail.com> wrote:
>
> > On Fri, 21 Aug 2020, Ayush wrote:
> >
> >> Hints to the first task:
> >>
> >> Can you create a list of all non-merge commits that were added in the
> >> version v5.8 of the kernel, i.e., all non-merge commits that are in v5.8
> >> and not already in v5.7?
> >>
> >> Can you share the script/command you executed and the resulting list on
> >> github?
> >>
> >> Can you run your script on all commits of this list above and record
> >> all checkpatch.pl reports, and store them in your github repository?
> >>
> >> Can you suggest ideas how to aggregate the findings and create a
> >> statistics? For example: Which type of error is reported most?
> >> Can you implement that idea?
> >>
> >> I also suggest to have a look at
> >> the options ./scripts/checkpatch.pl --list-types and
> >> ./scripts/checkpatch.pl --show-types. The option --show-types changes
> >> the output of checkpatch.pl to list type identifiers, so it is easier
> >> to parse and aggregate the output.
> >>
> >> Please also share the script you create for that purpose on your
> >> github repository.
> >>
> >> The second task is to pick one warning that appears often and improve
> >> checkpatch.pl to handle that better and get it accepted by the kernel
> >> community.
> >>
> >> Hints to the second task follow when the first task is solved.
> >>
> >> If you fail on any of those tasks, you are out of the selection process.
> >>
> >> Lukas
> >>
> >> Sir,
> >>
> >> I have attempted the task 1 and pushed the same to GitHub.
> >>
> >> Please have a look and suggest improvements.
> >>
> >> https://github.com/eldraco19/evalute_improve_checkpatch_pl
> >>
> >> Please let me know if there are any issues with this.
> >
> > So far, so good.
> >
> > Here are the questions we want to answer:
> >
> > - So what are the 20 categories that occur most?
> >
> > You are getting close to that answer, but you are not there yet.
> >
> > Then look at the findings. For those 20 categories, are there specific
> > findings that are multiple times false positives?
> >
> > So, the script complains about something, but it does not get that the
> > patch author wrote something completely unrelated to the error message.
> >
> > Lukas
>
> Sir,
>
> I tried the given tasks and it can be found here,
>
> https://github.com/eldraco19/evalute_improve_checkpatch_pl/blob/master/STATS.md
>
The solution is implemented a bit complicated, but well, at least, it
works if I believe your report. (I only read the code, but did not run
it.)
The goal now is to find a class of false positives and improve
checkpatch.pl accordingly.
I suggest that you look at the specific DIFF_IN_COMMIT_MSG reported
errors?
Provide a short assessment for each DIFF_IN_COMMIT_MSG error in the
10 commits.
It should tell:
- what lines in the commit message did checkpatch.pl complain about?
- what is the pattern in the commit message?
- does patch(1) really stumble over that pattern?
- how would this pattern need to be provided to patch(1) so that it
would stumble over it?
- if no, why not?
- can we change checkpatch.pl to not raise an error for such a
situation? So, only raise an error when the pattern would really make
patch stumble on it?
Depending on the evaluation, we might continue to improve checkpatch.pl
for reporting this error type, or we decide to look at GIT_COMMIT_ID
errors, where I can quickly spot some false positives.
Best regards,
Lukas
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
next prev parent reply other threads:[~2020-08-27 5:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200810125354.xeijyh3v5upatrez@salamander>
2020-08-17 9:43 ` [Linux-kernel-mentees] Regarding "Linux Kernel: Evaluate and Improve checkpatch.pl" Lukas Bulwahn
2020-08-21 16:18 ` Ayush
2020-08-22 8:06 ` Lukas Bulwahn
2020-08-24 10:06 ` Ayush
2020-08-27 5:28 ` Lukas Bulwahn [this message]
2020-08-30 18:51 ` Ayush
2020-08-31 5:14 ` Lukas Bulwahn
2020-09-06 9:59 ` Ayush
2020-09-07 7:38 ` Lukas Bulwahn
2020-09-07 14:27 ` Ayush
2020-09-07 16:43 ` Lukas Bulwahn
2020-09-09 9:14 ` Ayush
2020-09-09 9:52 ` Lukas Bulwahn
2020-09-09 16:01 ` Ayush
2020-09-10 6:04 ` Lukas Bulwahn
2020-08-26 13:51 ` Ayush
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* 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.2008270707440.9436@felia \
--to=lukas.bulwahn@gmail.com \
--cc=ayush@disroot.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).