* Mentorship report first draft
@ 2021-03-12 17:44 Dwaipayan Ray
2021-03-20 14:03 ` Lukas Bulwahn
0 siblings, 1 reply; 6+ messages in thread
From: Dwaipayan Ray @ 2021-03-12 17:44 UTC (permalink / raw)
To: Lukas Bulwahn, linux-kernel-mentees
[-- Attachment #1: Type: text/plain, Size: 259 bytes --]
Hello,
As discussed earlier, attached is the initial draft of the mentorship report.
Please let me know in case you have any suggestions.
Also you can view it live at
https://raydwaipayan.github.io/blogs/posts/linux-kernel-mentorship/
Thank you!
Dwaipayan.
[-- Attachment #2: linux-kernel-mentorship.md --]
[-- Type: text/markdown, Size: 5313 bytes --]
---
title: "Linux Kernel checkpatch.pl mentorship"
date: 2021-03-06T02:05:17+05:30
draft: false
---
## Checkpatch - What is it?
[checkpatch.pl](https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl) is a trivial style checker for patches sent to the linux kernel.
Why is it needed you say?</br>
I did an analysis on checkpatch warnings on about 50k commits from v5.4.</br>
(Find the full report {{% link checkpatch_out_50k.txt %}}here{{% /link %}})
The top errors were then generated via the following shell command:
```/bin/bash
cat checkpatch_out_50k.txt | grep -oP "(?:WARNING|ERROR|CHECK):(\w+)" \
| sort | uniq -c | sort -nr | head -n6
```
Count of errors | Error Types | Error
----------------|-------------|------
41999 | <span style="color:green">CHECK</span> | CAMELCASE
13629 | <span style="color:green">CHECK</span> | PARENTHESIS_ALIGNMENT
11491 | <span style="color:orange">WARNING</span> | LONG_LINE
8106 | <span style="color:green">CHECK</span> | SPACING
6825 | <span style="color:orange">WARNING</span> | LEADING_SPACE
4394 | <span style="color:green">CHECK</span> | OPEN_ENDED_LINE
Hmm...The no. of stylistically incorrect bits still continue to exist and
are still merged into the kernel code. To make the kernel code more
stylistically coherent, we can:
> - Create cleanup patches for the existing code
> - Make sure new patches are stylistically consistent
Both of these are where checkpatch comes handy.
## Checkpatch in the patch submission process
Before sending out the patches to the mailing list, it is recommended to
run checkpatch over the patches.
In general, a Kernel developer would:
> - Create the patch with his proposed changes.
> - Build check the patch, run additional tools like checkstack, sparse etc.
> - Run checkpatch.pl over the patches to eliminate all trivial style violations.
> - Send out the patch to the maintainers and mailing list.
The only catch here is that checkpatch is not always right. It is just a dumb
perl script. If the code looks better with checkpatch errors, let it be.
## Drawbacks of checkpatch
Checkpatch is only a static trivial style checker. It does not have the
capabilities of a full c based parser like [clang-format](https://www.kernel.org/doc/html/latest/process/clang-format.html). In this sense it is limited in
what it can do. Still, it is highly valuable as a style checker tool and can
ease the work of maintainers and increase the chances of the patch being accepted
by the community.
## What did we do to improve it?
Over the first 3 months of my mentorship period, I primarily focused on
eliminating false-positives from checkpatch as well as adding new rules.
Consider the following patch commit log:
```diff
#include asm/bitsperlong.h avoid further potential userspace pollution
by moving the #define of SHIFT_PER_LONG to bitops.h which is not
exported to userspace.
```
A kernel developer in 2020 would not see any checkpatch warning.
A kernel developer in 2021 would see the following warning:
```\bin\bash
WARNING: Commit log lines starting with '#' are dropped by git as comments
#82:
#include asm/bitsperlong.h avoid further potential userspace pollution
```
During the last 3 months I worked on two major features:
> - Addition of a verbose mode to checkpatch
> - Addition of an external documentation to checkpatch
For the documentation we decided to document all checkpatch message types,
their meanings and how to resolve them. This is still a work in progress.
Contributions are definitely welcome :-P.
### Verbose Mode
This was one of the new additions we did to checkpatch.
One can run checkpatch like this:
```/bin/bash
./scripts/checkpatch.pl -v test.patch
```
All verbose descriptions can be seen by pairing the verbose option
with --list-types:
```/bin/bash
./scripts/checkpatch.pl --list-types -v
```
### Checkpatch Documentation
The checkpatch documentation can be viewed from the kernel root
at `Documentation/dev-tools/checkpatch.rst`.
To build the documentation make sure you have configured sphynx
either in the system or in a python virtualenv. Next the kernel
doc can be built using:
```/bin/bash
make htmldocs
```
## How to contribute to the documentation?
The documentation is still a work in progress. Feel free to send
the patches to the kernel-doc mailing list, and add me (Dwaipayan
Ray <dwaipayanray1@gmail.com>) and Lukas (Lukas Bulwahn <lukas.bulwahn@gmail.com>) for reviewing it.
The documentation is writted in rst syntax. Refer
[here](http://openalea.gforge.inria.fr/doc/openalea/doc/_build/html/source/sphinx/rest_syntax.html) for a quick guide.
Before sending out the mail, please always:
> - checkpatch.pl your changes
> - build check your patch (in this case check the generated html docs)
> - spell check your patch (this can be easily done through checkpatch
> using --codespell flag if you already have the codespell dictionary)
## Acknowledgements
During my mentorship period I learned a lot from my mentors.
I would like to thank Lukas for his constant support as my mentor,
Joe for his guidance with checkpatch and everyone in the community for being such
amazing people.
The kernel contribution process may look old but it works. This is due to the dedication of everyone in the community, which I am glad to be a part of.
[-- Attachment #3: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Mentorship report first draft
2021-03-12 17:44 Mentorship report first draft Dwaipayan Ray
@ 2021-03-20 14:03 ` Lukas Bulwahn
2021-03-20 16:04 ` Dwaipayan Ray
0 siblings, 1 reply; 6+ messages in thread
From: Lukas Bulwahn @ 2021-03-20 14:03 UTC (permalink / raw)
To: Dwaipayan Ray; +Cc: linux-kernel-mentees
Dwaipayan, see my comments below inline.
Fix those minor issues, give the report to somebody else for another
review (and get some more comments), and then I think we are all good
to publish this.
Lukas
> ---
> title: "Linux Kernel checkpatch.pl mentorship"
> date: 2021-03-06T02:05:17+05:30
> draft: false
> ---
>
> ## Checkpatch - What is it?
> [checkpatch.pl](https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl) is a trivial style checker for patches sent to the linux kernel.
>
> Why is it needed you say?</br>
> I did an analysis on checkpatch warnings on about 50k commits from v5.4.</br>
> (Find the full report {{% link checkpatch_out_50k.txt %}}here{{% /link %}})
>
> The top errors were then generated via the following shell command:
> ```/bin/bash
> cat checkpatch_out_50k.txt | grep -oP "(?:WARNING|ERROR|CHECK):(\w+)" \
> | sort | uniq -c | sort -nr | head -n6
> ```
>
> Count of errors | Error Types | Error
> ----------------|-------------|------
> 41999 | <span style="color:green">CHECK</span> | CAMELCASE
> 13629 | <span style="color:green">CHECK</span> | PARENTHESIS_ALIGNMENT
> 11491 | <span style="color:orange">WARNING</span> | LONG_LINE
> 8106 | <span style="color:green">CHECK</span> | SPACING
> 6825 | <span style="color:orange">WARNING</span> | LEADING_SPACE
> 4394 | <span style="color:green">CHECK</span> | OPEN_ENDED_LINE
>
> Hmm...The no. of stylistically incorrect bits still continue to exist and
Drop the Hmm... or replace it by "As we can see,"
Replace no. by number. (It is not good to abbreviate here.)
> are still merged into the kernel code. To make the kernel code more
> stylistically coherent, we can:
>
> > - Create cleanup patches for the existing code
> > - Make sure new patches are stylistically consistent
>
> Both of these are where checkpatch comes handy.
>
> ## Checkpatch in the patch submission process
>
> Before sending out the patches to the mailing list, it is recommended to
> run checkpatch over the patches.
>
> In general, a Kernel developer would:
>
> > - Create the patch with his proposed changes.
> > - Build check the patch, run additional tools like checkstack, sparse etc.
maybe add "check for compiler warnings",
checkstack does not exist anymore.
such as sparse and coccinelle
> > - Run checkpatch.pl over the patches to eliminate all trivial style violations.
> > - Send out the patch to the maintainers and mailing list.
>
>
> The only catch here is that checkpatch is not always right. It is just a dumb
> perl script. If the code looks better with checkpatch errors, let it be.
>
This is fine to say for the author or as direct advice to a developer, here
I would phrase more neutral.
> ## Drawbacks of checkpatch
>
> Checkpatch is only a static trivial style checker. It does not have the
> capabilities of a full c based parser like [clang-format](https://www.kernel.org/doc/html/latest/process/clang-format.html). In this sense it is limited in
write instead
"a tool using a full-fledged C parser, such as clang-format"
> what it can do. Still, it is highly valuable as a style checker tool and can
> ease the work of maintainers and increase the chances of the patch being accepted
> by the community.
>
> ## What did we do to improve it?
>
> Over the first 3 months of my mentorship period, I primarily focused on
s/3/three/
(write out numbers up to twelve).
> eliminating false-positives from checkpatch as well as adding new rules.
>
s/false-positives/false positives/
> Consider the following patch commit log:
>
> ```diff
> #include asm/bitsperlong.h avoid further potential userspace pollution
> by moving the #define of SHIFT_PER_LONG to bitops.h which is not
> exported to userspace.
> ```
>
> A kernel developer in 2020 would not see any checkpatch warning.
>
> A kernel developer in 2021 would see the following warning:
> ```\bin\bash
> WARNING: Commit log lines starting with '#' are dropped by git as comments
> #82:
> #include asm/bitsperlong.h avoid further potential userspace pollution
> ```
>
> During the last 3 months I worked on two major features:
>
s/3/three/
> > - Addition of a verbose mode to checkpatch
> > - Addition of an external documentation to checkpatch
>
> For the documentation we decided to document all checkpatch message types,
> their meanings and how to resolve them. This is still a work in progress.
> Contributions are definitely welcome :-P.
>
Drop the :-P ; you are serious, we want to see contributions from others.
> ### Verbose Mode
>
> This was one of the new additions we did to checkpatch.
>
> One can run checkpatch like this:
>
> ```/bin/bash
> ./scripts/checkpatch.pl -v test.patch
> ```
>
> All verbose descriptions can be seen by pairing the verbose option
> with --list-types:
>
> ```/bin/bash
> ./scripts/checkpatch.pl --list-types -v
> ```
>
> ### Checkpatch Documentation
>
> The checkpatch documentation can be viewed from the kernel root
> at `Documentation/dev-tools/checkpatch.rst`.
>
simply:
The checkpatch documentation is at `Documentation/dev-tools/checkpatch.rst`
in the kernel repository.
> To build the documentation make sure you have configured sphynx
> either in the system or in a python virtualenv. Next the kernel
> doc can be built using:
>
> ```/bin/bash
> make htmldocs
> ```
>
> ## How to contribute to the documentation?
>
> The documentation is still a work in progress. Feel free to send
> the patches to the kernel-doc mailing list, and add me (Dwaipayan
> Ray <dwaipayanray1@gmail.com>) and Lukas (Lukas Bulwahn <lukas.bulwahn@gmail.com>) for reviewing it.
>
> The documentation is writted in rst syntax. Refer
> [here](http://openalea.gforge.inria.fr/doc/openalea/doc/_build/html/source/sphinx/rest_syntax.html) for a quick guide.
>
> Before sending out the mail, please always:
>
s/writted/written/
s/mail/patch/
> > - checkpatch.pl your changes
> > - build check your patch (in this case check the generated html docs)
> > - spell check your patch (this can be easily done through checkpatch
> > using --codespell flag if you already have the codespell dictionary)
>
> ## Acknowledgements
>
> During my mentorship period I learned a lot from my mentors.
> I would like to thank Lukas for his constant support as my mentor,
> Joe for his guidance with checkpatch and everyone in the community for being such
> amazing people.
>
> The kernel contribution process may look old but it works. This is due to the dedication of everyone in the community, which I am glad to be a part of.
I think you need to explain that this is something you learned in this
mentorship, and that newcomers might think at first, but where you
have been surprised.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Mentorship report first draft
2021-03-20 14:03 ` Lukas Bulwahn
@ 2021-03-20 16:04 ` Dwaipayan Ray
2021-03-25 6:23 ` Dwaipayan Ray
2021-03-25 7:59 ` Lukas Bulwahn
0 siblings, 2 replies; 6+ messages in thread
From: Dwaipayan Ray @ 2021-03-20 16:04 UTC (permalink / raw)
To: Lukas Bulwahn; +Cc: linux-kernel-mentees
On Sat, Mar 20, 2021 at 7:33 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
>
> Dwaipayan, see my comments below inline.
>
> Fix those minor issues, give the report to somebody else for another
> review (and get some more comments), and then I think we are all good
> to publish this.
Sure I will fix them. How are we going to publish it? We just share the link it
is hosted on or something else?
>
> Lukas
>
> > ---
> > title: "Linux Kernel checkpatch.pl mentorship"
> > date: 2021-03-06T02:05:17+05:30
> > draft: false
> > ---
> >
> > ## Checkpatch - What is it?
> > [checkpatch.pl](https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl) is a trivial style checker for patches sent to the linux kernel.
> >
> > Why is it needed you say?</br>
> > I did an analysis on checkpatch warnings on about 50k commits from v5.4.</br>
> > (Find the full report {{% link checkpatch_out_50k.txt %}}here{{% /link %}})
> >
> > The top errors were then generated via the following shell command:
> > ```/bin/bash
> > cat checkpatch_out_50k.txt | grep -oP "(?:WARNING|ERROR|CHECK):(\w+)" \
> > | sort | uniq -c | sort -nr | head -n6
> > ```
> >
> > Count of errors | Error Types | Error
> > ----------------|-------------|------
> > 41999 | <span style="color:green">CHECK</span> | CAMELCASE
> > 13629 | <span style="color:green">CHECK</span> | PARENTHESIS_ALIGNMENT
> > 11491 | <span style="color:orange">WARNING</span> | LONG_LINE
> > 8106 | <span style="color:green">CHECK</span> | SPACING
> > 6825 | <span style="color:orange">WARNING</span> | LEADING_SPACE
> > 4394 | <span style="color:green">CHECK</span> | OPEN_ENDED_LINE
> >
> > Hmm...The no. of stylistically incorrect bits still continue to exist and
>
> Drop the Hmm... or replace it by "As we can see,"
>
> Replace no. by number. (It is not good to abbreviate here.)
>
Okay will do.
> > are still merged into the kernel code. To make the kernel code more
> > stylistically coherent, we can:
> >
> > > - Create cleanup patches for the existing code
> > > - Make sure new patches are stylistically consistent
> >
> > Both of these are where checkpatch comes handy.
> >
> > ## Checkpatch in the patch submission process
> >
> > Before sending out the patches to the mailing list, it is recommended to
> > run checkpatch over the patches.
> >
> > In general, a Kernel developer would:
> >
> > > - Create the patch with his proposed changes.
> > > - Build check the patch, run additional tools like checkstack, sparse etc.
>
> maybe add "check for compiler warnings",
> checkstack does not exist anymore.
>
Oops the documentation seems to be outdated then.
https://www.kernel.org/doc/html/latest/process/submit-checklist.html
point no. 10
Will correct
> such as sparse and coccinelle
>
> > > - Run checkpatch.pl over the patches to eliminate all trivial style violations.
> > > - Send out the patch to the maintainers and mailing list.
> >
> >
> > The only catch here is that checkpatch is not always right. It is just a dumb
> > perl script. If the code looks better with checkpatch errors, let it be.
> >
>
> This is fine to say for the author or as direct advice to a developer, here
> I would phrase more neutral.
>
> > ## Drawbacks of checkpatch
> >
> > Checkpatch is only a static trivial style checker. It does not have the
> > capabilities of a full c based parser like [clang-format](https://www.kernel.org/doc/html/latest/process/clang-format.html). In this sense it is limited in
>
> write instead
> "a tool using a full-fledged C parser, such as clang-format"
>
> > what it can do. Still, it is highly valuable as a style checker tool and can
> > ease the work of maintainers and increase the chances of the patch being accepted
> > by the community.
> >
> > ## What did we do to improve it?
> >
> > Over the first 3 months of my mentorship period, I primarily focused on
>
> s/3/three/
>
> (write out numbers up to twelve).
>
> > eliminating false-positives from checkpatch as well as adding new rules.
> >
> s/false-positives/false positives/
> > Consider the following patch commit log:
> >
> > ```diff
> > #include asm/bitsperlong.h avoid further potential userspace pollution
> > by moving the #define of SHIFT_PER_LONG to bitops.h which is not
> > exported to userspace.
> > ```
> >
> > A kernel developer in 2020 would not see any checkpatch warning.
> >
> > A kernel developer in 2021 would see the following warning:
> > ```\bin\bash
> > WARNING: Commit log lines starting with '#' are dropped by git as comments
> > #82:
> > #include asm/bitsperlong.h avoid further potential userspace pollution
> > ```
> >
> > During the last 3 months I worked on two major features:
> >
>
> s/3/three/
>
> > > - Addition of a verbose mode to checkpatch
> > > - Addition of an external documentation to checkpatch
> >
> > For the documentation we decided to document all checkpatch message types,
> > their meanings and how to resolve them. This is still a work in progress.
> > Contributions are definitely welcome :-P.
> >
>
> Drop the :-P ; you are serious, we want to see contributions from others.
>
> > ### Verbose Mode
> >
> > This was one of the new additions we did to checkpatch.
> >
> > One can run checkpatch like this:
> >
> > ```/bin/bash
> > ./scripts/checkpatch.pl -v test.patch
> > ```
> >
> > All verbose descriptions can be seen by pairing the verbose option
> > with --list-types:
> >
> > ```/bin/bash
> > ./scripts/checkpatch.pl --list-types -v
> > ```
> >
> > ### Checkpatch Documentation
> >
> > The checkpatch documentation can be viewed from the kernel root
> > at `Documentation/dev-tools/checkpatch.rst`.
> >
>
> simply:
> The checkpatch documentation is at `Documentation/dev-tools/checkpatch.rst`
> in the kernel repository.
>
> > To build the documentation make sure you have configured sphynx
> > either in the system or in a python virtualenv. Next the kernel
> > doc can be built using:
> >
> > ```/bin/bash
> > make htmldocs
> > ```
> >
> > ## How to contribute to the documentation?
> >
> > The documentation is still a work in progress. Feel free to send
> > the patches to the kernel-doc mailing list, and add me (Dwaipayan
> > Ray <dwaipayanray1@gmail.com>) and Lukas (Lukas Bulwahn <lukas.bulwahn@gmail.com>) for reviewing it.
> >
> > The documentation is writted in rst syntax. Refer
> > [here](http://openalea.gforge.inria.fr/doc/openalea/doc/_build/html/source/sphinx/rest_syntax.html) for a quick guide.
> >
> > Before sending out the mail, please always:
> >
>
> s/writted/written/
> s/mail/patch/
>
> > > - checkpatch.pl your changes
> > > - build check your patch (in this case check the generated html docs)
> > > - spell check your patch (this can be easily done through checkpatch
> > > using --codespell flag if you already have the codespell dictionary)
> >
> > ## Acknowledgements
> >
> > During my mentorship period I learned a lot from my mentors.
> > I would like to thank Lukas for his constant support as my mentor,
> > Joe for his guidance with checkpatch and everyone in the community for being such
> > amazing people.
> >
>
> > The kernel contribution process may look old but it works. This is due to the dedication of everyone in the community, which I am glad to be a part of.
>
> I think you need to explain that this is something you learned in this
> mentorship, and that newcomers might think at first, but where you
> have been surprised.
Yes sure I will be elaborating a bit on these. I feel that I should be able
to motivate others to enter this process.
Thanks for the review Lukas. I will be making the necessary changes.
Thanks & Regards,
Dwaipayan.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Mentorship report first draft
2021-03-20 16:04 ` Dwaipayan Ray
@ 2021-03-25 6:23 ` Dwaipayan Ray
2021-03-25 7:59 ` Lukas Bulwahn
1 sibling, 0 replies; 6+ messages in thread
From: Dwaipayan Ray @ 2021-03-25 6:23 UTC (permalink / raw)
To: Lukas Bulwahn; +Cc: linux-kernel-mentees
> Thanks for the review Lukas. I will be making the necessary changes.
>
Hello,
Please see the updated document below.
If you feel it's fine then maybe we can proceed with this.
-----------------
## Checkpatch - What is it?
[checkpatch.pl](https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl)
is a trivial style checker for patches sent to the linux kernel.
Why is it needed you say?</br>
I did an analysis on checkpatch warnings on about 50k commits from v5.4.</br>
(Find the full report {{% link checkpatch_out_50k.txt %}}here{{% /link %}})
The top errors were then generated via the following shell command:
```/bin/bash
cat checkpatch_out_50k.txt | grep -oP "(?:WARNING|ERROR|CHECK):(\w+)" \
| sort | uniq -c | sort -nr | head -n6
```
Count of errors | Error Types | Error
----------------|-------------|------
41999 | <span style="color:green">CHECK</span> | CAMELCASE
13629 | <span style="color:green">CHECK</span> | PARENTHESIS_ALIGNMENT
11491 | <span style="color:orange">WARNING</span> | LONG_LINE
8106 | <span style="color:green">CHECK</span> | SPACING
6825 | <span style="color:orange">WARNING</span> | LEADING_SPACE
4394 | <span style="color:green">CHECK</span> | OPEN_ENDED_LINE
As we can see, the number of stylistically incorrect bits still continue
to exist and are still merged into the kernel code. To make the kernel
code more stylistically coherent, we can:
> - Create cleanup patches for the existing code
> - Make sure new patches are stylistically consistent
Both of these are where checkpatch comes handy.
## Checkpatch in the patch submission process
Before sending out the patches to the mailing list, it is recommended to
run checkpatch over the patches.
In general, a Kernel developer would:
> - Create the patch with his proposed changes.
> - Build check the patch and lookout for compiler warnings.
> - Run additional tools such as sparse, KASAN, etc.
> - Run checkpatch.pl over the patches to eliminate all trivial style violations.
> - Send out the patch to the maintainers and mailing list.
It is to be noted that checkpatch is not always right. And at times the
author's judgement should take precedence over checkpatch.
## Drawbacks of checkpatch
Checkpatch is only a static trivial style checker. It does not have the
capabilities of a tool using a full-fledged C parser, such as
[clang-format](https://www.kernel.org/doc/html/latest/process/clang-format.html)
. In this sense it is limited in what it can do.
Still, it is highly valuable as a style checker tool and can ease the
work of maintainers and increase the chances of the patch being
accepted by the community.
## What did we do to improve it?
Over the first three months of my mentorship period, I primarily focused on
eliminating false-positives from checkpatch as well as adding new rules.
Consider the following patch commit log:
```diff
#include asm/bitsperlong.h avoid further potential userspace pollution
by moving the #define of SHIFT_PER_LONG to bitops.h which is not
exported to userspace.
```
A kernel developer in 2020 would not see any checkpatch warning.
A kernel developer in 2021 would see the following warning:
```\bin\bash
WARNING: Commit log lines starting with '#' are dropped by git as comments
#82:
#include asm/bitsperlong.h avoid further potential userspace pollution
```
During the last three months I worked on two major features:
> - Addition of a verbose mode to checkpatch
> - Addition of an external documentation to checkpatch
For the documentation we decided to document all checkpatch message types,
their meanings and how to resolve them. This is still a work in progress.
Contributions are definitely welcome.
### Verbose Mode
This was one of the new additions we did to checkpatch.
One can run checkpatch like this:
```/bin/bash
./scripts/checkpatch.pl -v test.patch
```
All verbose descriptions can be seen by pairing the verbose option
with --list-types:
```/bin/bash
./scripts/checkpatch.pl --list-types -v
```
### Checkpatch Documentation
The checkpatch documentation is at `Documentation/dev-tools/checkpatch.rst`
in the kernel repository.
To build the documentation make sure you have configured sphynx
either in the system or in a python virtualenv. Next the kernel
doc can be built using:
```/bin/bash
make htmldocs
```
## How to contribute to the documentation?
The documentation is still a work in progress. Feel free to send
the patches to the kernel-doc mailing list, and add me
(Dwaipayan Ray <dwaipayanray1@gmail.com>) and Lukas (Lukas Bulwahn
<lukas/bulwahn@gmail.com>)
for reviewing it.
The documentation is written in rst syntax. Refer
[here](http://openalea.gforge.inria.fr/doc/openalea/doc/_build/html/source/sphinx/rest_syntax.html)
for a quick guide.
Before sending out the patch, please always:
> - checkpatch.pl your changes
> - build check your patch (in this case check the generated html docs)
> - spell check your patch (this can be easily done through checkpatch
> using --codespell flag if you already have the codespell dictionary)
## Acknowledgements
During my mentorship period I learned a lot from my mentors.
I would like to thank Lukas for his constant support as my mentor,
Joe for his guidance with checkpatch and everyone in the community for being
such amazing people.
The kernel contribution process may look old but it works. At the beginning
when I started sending my initial patches, it looked like a tiring and
unnecessary process. I was more accustomed to creating pull requests rather
than sending patches over mail.
Slowly I found out that scripts like get_maintainer.pl actually lets you easily
find the people associated with that particular code. After finding those
people it's very easy to send the patches to the list and the associated
people. This follows a period of extensive review which is very useful for
having good code. I have got lots of reviews from people in the community
and those patches are successfully merged into the mainline.
So I was really amazed by the process. What is even more amazing is that the
newcomers won't get lost in this extensive process. There are always
people who help and encourage others to create good patches. And that
makes me glad to say that I too am a part of this community.
-------------------
Thanks!
Dwaipayan.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Mentorship report first draft
2021-03-20 16:04 ` Dwaipayan Ray
2021-03-25 6:23 ` Dwaipayan Ray
@ 2021-03-25 7:59 ` Lukas Bulwahn
2021-03-27 15:08 ` Dwaipayan Ray
1 sibling, 1 reply; 6+ messages in thread
From: Lukas Bulwahn @ 2021-03-25 7:59 UTC (permalink / raw)
To: Dwaipayan Ray; +Cc: linux-kernel-mentees
On Sat, Mar 20, 2021 at 5:04 PM Dwaipayan Ray <dwaipayanray1@gmail.com> wrote:
>
> On Sat, Mar 20, 2021 at 7:33 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> >
> > Dwaipayan, see my comments below inline.
> >
> > Fix those minor issues, give the report to somebody else for another
> > review (and get some more comments), and then I think we are all good
> > to publish this.
>
> Sure I will fix them. How are we going to publish it? We just share the link it
> is hosted on or something else?
>
We can of course share it as a link; I will check if there is a blog
to publish this on for the LF mentorship program.
Otherwise, I think https://people.kernel.org/read might be a good place as well.
Lukas
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Mentorship report first draft
2021-03-25 7:59 ` Lukas Bulwahn
@ 2021-03-27 15:08 ` Dwaipayan Ray
0 siblings, 0 replies; 6+ messages in thread
From: Dwaipayan Ray @ 2021-03-27 15:08 UTC (permalink / raw)
To: Lukas Bulwahn; +Cc: linux-kernel-mentees
On Thu, Mar 25, 2021 at 1:30 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
>
> On Sat, Mar 20, 2021 at 5:04 PM Dwaipayan Ray <dwaipayanray1@gmail.com> wrote:
> >
> > On Sat, Mar 20, 2021 at 7:33 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > >
> > > Dwaipayan, see my comments below inline.
> > >
> > > Fix those minor issues, give the report to somebody else for another
> > > review (and get some more comments), and then I think we are all good
> > > to publish this.
> >
> > Sure I will fix them. How are we going to publish it? We just share the link it
> > is hosted on or something else?
> >
>
> We can of course share it as a link; I will check if there is a blog
> to publish this on for the LF mentorship program.
>
> Otherwise, I think https://people.kernel.org/read might be a good place as well.
>
Either way is nice I think.
Please let me know what I can do next.
Thanks!
Dwaipayan.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-03-27 15:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-12 17:44 Mentorship report first draft Dwaipayan Ray
2021-03-20 14:03 ` Lukas Bulwahn
2021-03-20 16:04 ` Dwaipayan Ray
2021-03-25 6:23 ` Dwaipayan Ray
2021-03-25 7:59 ` Lukas Bulwahn
2021-03-27 15:08 ` Dwaipayan Ray
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.