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: > > On Tue, Oct 17, 2017 at 08:57:13AM -0700, James Bottomley wrote: > > > > > > On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote: > > > > > > > > > > > > > > > > > > > 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
