[<prev] [next>] [day] [month] [year] [list]
Message-ID: <f3514471-9978-4aad-af40-e4970827a61b@web.de>
Date: Tue, 25 Jun 2024 21:50:33 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Suman Ghosh <sumang@...vell.com>, netdev@...r.kernel.org
Cc: LKML <linux-kernel@...r.kernel.org>, "David S. Miller"
<davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Jerin Jacob <jerinj@...vell.com>, Eric Dumazet <edumazet@...gle.com>,
Geethasowjanya Akula <gakula@...vell.com>,
Hariprasad Kelam <hkelam@...vell.com>, Linu Cherian <lcherian@...vell.com>,
Paolo Abeni <pabeni@...hat.com>,
Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
Sunil Kovvuri Goutham <sgoutham@...vell.com>
Subject: Re: [net PATCH v2 0/7] octeontx2-af: Fix klockwork issues in AF
driver
> > * Why did you not directly respond to the recurring patch review concern
> > about better summary phrases (or message subjects)?
…
> [Suman] I thought the “summery phrase” is per patch.
Summaries are obviously important parts for patch subjects.
> The cover letter is mentioning the reason for the change
I would like to read an improved overview for your change approach.
> and each patch set is adding the summery for the change.
I have got understanding difficulties for such information somehow.
> Since it is not some actual ‘fix’ I am not sure what more to add other
It seems that there is a temporary conflict according to expected explanation quality.
> than mentioning klockwork fixes.
Source code analysis tools can provide more helpful information.
Do I need to remind you for the published software documentation
around “C checkers”?
> I am not sure what more can be added for a variable initialization to zero
> or adding a NULL check.
* Common vulnerability enumeration?
* CERT reference?
> Can you suggest some?
* Please take another look at linked information sources.
* Can you get sufficient inspirations from published patches?
> > * Would you like to explain any more here which development concern categories
> > were picked up from the mentioned source code analysis tool?
>
> [Suman] Development concerns are mentioned in individual patch sets.
* Grouping?
* Outlines?
* Taxonomy?
> > * How much do you care for the grouping of logical changes into
> > consistent patch series?
>
> [Suman] I thought about it but then I was not sure
> how to add fix tags for a unified patch set.
Why did you not ask before sending another questionable patch series?
> Hence went with per file approach.
It can occasionally be helpful for change preparations.
> Do you see any problem with the approach?
Obviously, yes.
I hope that you can take several patch review issues better into account finally.
Regards,
Markus
Powered by blists - more mailing lists