On Wed, Oct 18, 2017 at 09:09:48AM -0700, James Bottomley wrote:

On Wed, 2017-10-18 at 18:10 +0300, Jarkko Sakkinen wrote:

quoted

On Tue, Oct 17, 2017 at 08:57:13AM -0700, James Bottomley wrote:

quoted

On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote:

quoted

quoted

Fixes is only for bug fixes.  These don't fix any bugs.

How do you distinguish these in questionable source code
from other error categories or software weaknesses?

A style change is one that doesn't change the effect of the
execution.
 These don't actually even change the assembly, so there's
programmatic
proof they're not fixing anything.

Bug means potentially user visible fault.  In any bug fix commit
you
should document the fault and its effects on users so those
backporting
can decide if they care or not.

James

OK, I'll adjust my definition of a bug :-)

Subsystems are free to define bugs in any reasonable way.  However,
there are two things to note here:

   1. The style guide is just that, a guide; it's not hard and fast rules.
       That means that violations aren't bugs in the usual sense.
       However, new code should mostly follow it and if it doesn't, there
      should be a good reason to go against the guide which should be
      explained in the change log.
   2. The coding style evolves, so older drivers usually don't conform.
       Classifying coding style issues as bugs leads to tons of patches
      "fixing" older drivers, some of which actually end up breaking the
      drivers in subtle ways which take ages to be found (at least that's
      what we've seen in SCSI).

James

Makes sense. Thanks for verbose explanation.

/Jarkko