[PATCH 0/2] md: Replace snprintf with scnprintf

Andrea Righi andrea.righi at canonical.com
Wed Oct 19 08:54:18 UTC 2022


On Wed, Oct 19, 2022 at 10:08:09AM +0200, Stefan Bader wrote:
> On 18.10.22 17:13, Tim Gardner wrote:
> > BugLink: https://bugs.launchpad.net/bugs/1993315
> > 
> > SRU Justification
> > 
> > While this patch was originally requested by the Microsoft Azure team, it seems
> > appropriate for the generic kernel as well.
> 
> In my joyful morning mood I am tempted to NACK this for formal reasons. Why
> does the cover email not contain any indication where it should go to? Why
> do the patches invent yet another way to define where they apply to?
> 
> Andrea, Cory,
> 
> that would be a question which you could ask. Ideally (and I thought that
> was what is documented) this should have looked like:
> 
> [SRU K/J/F][PATCH 0/1] ...
> - [SRU K][PATCH 1/1] ...
> - [SRU J/F][PATCH 1/1] ...
> 
> If that was not for the primary kernel (or if one wants to be explicit) it
> should be more like the handle format, so "K:linux" or "J/F:linux". There is
> already use of source names without series mixed with series which is a bit
> of a pain to read.
> 
> Note that this is "Re" and not "NACK".
> 
> -Stefan

I was also tempted to comment that the subject wasn't properly
formatted, maybe I was just feeling too nice this morning. :)

Jokes apart, I agree that coding style and patch format in general is
super important, if everything is properly formatted we can work more
efficiently and better, because our brain can immediately recognize
"known" patterns.

Hence my response here, not to criticize too much the original emails,
but to emphasize the importance of coding style (at the end apart from
the subject everything else was correct, with a nice SRU template...
that is missing a '[ Test Plan ]' section, but I've seen worse).

So +1 on Stefan comment.

-Andrea



More information about the kernel-team mailing list