archive mirror
 help / color / mirror / Atom feed
* Re: [Linux-kernel-mentees] Application for Linux CommunityBridge Mentorship Programme
       [not found]   ` <0fd328a1-63d0-42ce-8963-0bafad4c9675@Spark>
@ 2020-08-13  4:44     ` Lukas Bulwahn
  0 siblings, 0 replies; only message in thread
From: Lukas Bulwahn @ 2020-08-13  4:44 UTC (permalink / raw)
  To: ishan srivastava; +Cc: linux-kernel-mentees

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

On Thu, 13 Aug 2020, ishan srivastava wrote:

> Hello Lukas, thanks for the reply. I have been trying to come up with a solution to the bug and I have to say that I haven’t been able to come up with one that is neat and clean.

Okay, let us start easy here.

1. Please always CC:
2. Your email client is broken; you will not be able to communicate with 
the kernel community with a broken email client. Please follow the 
> The problem described in the bug refers to false positive warnings that are encountered for missing blank lines after declarations inside a struct.
> While I found no rule regarding this on, I presumed that this is a problem and went ahead to devise a solution.

3. What is the latest kernel version? From which year is the documentation 
you looked at and referred to? Please always look at the latest version 
(at least the latest tag in torvalds' tree) of the documentation and 
refer to that.

> The code in lines 3484-3523 ensures that there is a blank line in between declarations. To ensure that these checks are skipped when the line being checked by is inside a struct, we need to maintain a
> counter as to the depth of nested structs the current line in and skip the checks whenever inside even a single struct (keeping aside further complications like do different struct declarations still need line break between them)

4. Why are line numbers alone meaningless in an email? Think about the 
needed information that the reader can actually know what part of code you 
are referring to? (Hint: There is only one version of the kernel sources 
and it has not changed a single bit in the last 15 years, right?)
What conveys the complete state of a git source code repository in a short 
and unambiguous way?

Now to the technical discussion:

> If I have conveyed my concerns correctly then we can see that we will introduce a level of complication to as to which kind of paradigms the current line is in, which is currently not supported.
> I can go ahead and submit a patch and also show that to you if you wish so but I am not sure whether it would be accepted by the maintainers as from what I have inferred, this level of complication hasn’t been introduced in

Has this issue of a false positive from appeared on 
multiple commits in the last 10 years? How about finding out how often 
this rule would have emitted a true positive and a false positive on the 
commits of the last 10 years?

> I believe some other linters or static analysis tools can perform this with a few lines of code in their config file.

That is certainly an alternative; do you a specific tool in mind and can 
you share the configuration to obtain the cases you consider true positive 
> Please let me know what you think about this and what should be my next steps regarding this. I also find this interesting since even though not mentioned anywhere I see this coding style being followed in most places and might just be
> one of the false positives that we are looking forward to fix through this project. I would also like to know if you have any framework/methodology in mind to approaching these problem (as this is a problem that needs to be addressed
> by this project) or should we directly introduce this complexity to

Please address the points 1. to 4. correctly first; if you cannot get that 
solved, set up and you cannot follow the process, there is no chance for a 
kernel-related mentorship.

Once you solved that, think about how to send an email correctly now and 
compare it to first email. Send this improved email addressing the points 
1 to 4. above. Then we can continue the technical discussion.


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

Linux-kernel-mentees mailing list

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-08-13  4:44 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200803181312.GA28716@Ishans-MacBook-Pro.local>
     [not found] ` <>
     [not found]   ` <0fd328a1-63d0-42ce-8963-0bafad4c9675@Spark>
2020-08-13  4:44     ` [Linux-kernel-mentees] Application for Linux CommunityBridge Mentorship Programme Lukas Bulwahn

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