Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Lukas Bulwahn <lukas.bulwahn@gmail.com>
Date:   Sun, 25 Oct 2020 06:51:19 +0100 (CET)
To:     Joe Perches <joe@perches.com>
cc:     Aditya <yashsri421@gmail.com>,
        Lukas Bulwahn <lukas.bulwahn@gmail.com>,
        linux-kernel@vger.kernel.org,
        linux-kernel-mentees@lists.linuxfoundation.org,
        dwaipayanray1@gmail.com
Subject: Re: [PATCH v3] checkpatch: fix false positives in REPEATED_WORD
 warning
In-Reply-To: <5c11f284872f3b2b017d9d27d4075582c1a40eab.camel@perches.com>
Message-ID: <alpine.DEB.2.21.2010250627370.6697@felia>
References: <20201023133828.19609-1-yashsri421@gmail.com> <alpine.DEB.2.21.2010232104150.11676@felia> <c9512657-d7d0-bf04-0e40-b3463c9f5e1b@gmail.com> <5c11f284872f3b2b017d9d27d4075582c1a40eab.camel@perches.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk


On Sat, 24 Oct 2020, Joe Perches wrote:

> On Sat, 2020-10-24 at 18:54 +0530, Aditya wrote:
> > > Would you like to work on 
> > > further rules that can be improved with your evaluation approach?
> > 
> > Yes, I would like work on further rules.
> 
> Some generic ideas:
> 
> How about working to reduce runtime and complexity by
> making the rules extensible or separable at startup.
> 
> Maybe move each existing rules into a separate
> directory as an individual file and aggregate them at
> checkpatch startup.
> 
> Maybe look at the existing rules that do not have a
> $fix option and add them as appropriate.
>

I certainly support working on fixes.

I have this crazy dream that:

We can identify a set of rules and clear automatic fixes that
maintainers can simply run this script over the patches they pick
up when they pick them up.
Realistically in an easy interactive mode that works with the maintainers' 
workflow, so they simply confirm the automatic fixes where the script 
cannot be 100% sure that the quick fix is the right thing to do.

I think for commit message fixes that would be very nice.
E.g., correcting URLs, normalizing tags, correcting obvious typos.
 
> You could fix the multiline indentation where the
> current warning and fix is only for a single line
> 
> 	value = function(arg1,
> 		arg2,
> 		arg3);
> 
> where checkpatch emits only single warning and fix
> for the line with arg2, but not the line with arg3);
> 
> Maybe try to make the coding styles supported more
> flexible:
> 
> Allow braces in different places, support different
> tab indentation sizes, spacing rules around operators,
> function definition layouts, etc.
> 
>

This is a nice idea as well. And I recommend to do this kind of research 
looking at checkpatch and clang-format; both will not be the 'final tools' 
but I think if you can identify a good mix and combination of those two 
tools, we will get a good step forward of documenting the 
commonalities and differences of coding styles in the different 
subcommunities (the preferences of specific maintainers and subsystems).

A last nice idea to consider:

I would like to have an interactive checkpatch.pl mode where an authors
can say that they ran checkpatch.pl, seen the warning and errors 
reported, but disagree and comment why they disagree. Then this kind of
information is added to the patch in a non-disturbing area of the patch
and we can pick up and aggregate that information from the patches to see
the complaints, false positives to address or suggestions which rules
should be disabled for some subcommunities.

Aditya, your task is now to make those ideas more specific and write down 
a one to two page project proposal for the mentorship. It can be to some 
extent in bullet points as long as it is roughly understandable to all of 
us what you plan and would like to do.

With that proposal accepted, you have shown to be applicable to the 
mentorship program here and we take care of the last organisational points 
before the start.

Lukas