diff for duplicates of <1508342988.3958.5.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 36377c4..f1e57d9 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,18 +5,18 @@ On Wed, 2017-10-18 at 18:10 +0300, Jarkko Sakkinen wrote: > > > > > > > > > > > -> > > > Fixes is only for bug fixes. These don't fix any bugs. +> > > > 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 +> > 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 +> > Bug means potentially user visible fault. In any bug fix commit > > you > > should document the fault and its effects on users so those > > backporting @@ -26,16 +26,16 @@ On Wed, 2017-10-18 at 18:10 +0300, Jarkko Sakkinen wrote: > > OK, I'll adjust my definition of a bug :-) -Subsystems are free to define bugs in any reasonable way. However, +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 + 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 + 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). diff --git a/a/content_digest b/N1/content_digest index 01ec6cc..0452862 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,7 +7,7 @@ "ref\020171018151010.r4ojcpzs5l7rpt6r@linux.intel.com\0" "From\0James Bottomley <James.Bottomley@hansenpartnership.com>\0" "Subject\0Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations\0" - "Date\0Wed, 18 Oct 2017 16:09:48 +0000\0" + "Date\0Wed, 18 Oct 2017 09:09:48 -0700\0" "To\0Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>\0" "Cc\0SF Markus Elfring <elfring@users.sourceforge.net>" Dan Carpenter <dan.carpenter@oracle.com> @@ -35,18 +35,18 @@ "> > > \n" "> > > > \n" "> > > > \n" - "> > > > Fixes is only for bug fixes.\302\240\302\240These don't fix any bugs.\n" + "> > > > Fixes is only for bug fixes. These don't fix any bugs.\n" "> > > \n" "> > > How do you distinguish these in questionable source code\n" "> > > from other error categories or software weaknesses?\n" "> > \n" "> > A style change is one that doesn't change the effect of the\n" "> > execution.\n" - "> > \302\240These don't actually even change the assembly, so there's\n" + "> > These don't actually even change the assembly, so there's\n" "> > programmatic\n" "> > proof they're not fixing anything.\n" "> > \n" - "> > Bug means potentially user visible fault. \302\240In any bug fix commit\n" + "> > Bug means potentially user visible fault. In any bug fix commit\n" "> > you\n" "> > should document the fault and its effects on users so those\n" "> > backporting\n" @@ -56,20 +56,20 @@ "> \n" "> OK, I'll adjust my definition of a bug :-)\n" "\n" - "Subsystems are free to define bugs in any reasonable way. \302\240However,\n" + "Subsystems are free to define bugs in any reasonable way. However,\n" "there are two things to note here:\n" "\n" " 1. The style guide is just that, a guide; it's not hard and fast rules.\n" - " \302\240That means that violations aren't bugs in the usual sense.\n" - " \302\240However, new code should mostly follow it and if it doesn't, there\n" + " That means that violations aren't bugs in the usual sense.\n" + " However, new code should mostly follow it and if it doesn't, there\n" " should be a good reason to go against the guide which should be\n" " explained in the change log.\n" " 2. The coding style evolves, so older drivers usually don't conform.\n" - " \302\240Classifying coding style issues as bugs leads to tons of patches\n" + " Classifying coding style issues as bugs leads to tons of patches\n" " \"fixing\" older drivers, some of which actually end up breaking the\n" " drivers in subtle ways which take ages to be found (at least that's\n" " what we've seen in SCSI).\n" "\n" James -c1ccedb27a924b58f6c913c05a930d7b5568b4f0f876f7f41095796fe978efdb +664085f155843ae0384b5c8de0539b4b661dc46e0802d21c38c35a7729af8d9a
diff --git a/a/content_digest b/N2/content_digest index 01ec6cc..96593a8 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -7,7 +7,7 @@ "ref\020171018151010.r4ojcpzs5l7rpt6r@linux.intel.com\0" "From\0James Bottomley <James.Bottomley@hansenpartnership.com>\0" "Subject\0Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations\0" - "Date\0Wed, 18 Oct 2017 16:09:48 +0000\0" + "Date\0Wed, 18 Oct 2017 09:09:48 -0700\0" "To\0Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>\0" "Cc\0SF Markus Elfring <elfring@users.sourceforge.net>" Dan Carpenter <dan.carpenter@oracle.com> @@ -72,4 +72,4 @@ "\n" James -c1ccedb27a924b58f6c913c05a930d7b5568b4f0f876f7f41095796fe978efdb +6cf7ccbf225bc15ba4a77e8951778c5f4f57ae3c30a2f1764d70dd073b7b2a61
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.