diff for duplicates of <20180705162010.GA18499@kroah.com> diff --git a/a/1.txt b/N1/1.txt index 3dab6a3..cea3ce5 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -6,7 +6,7 @@ On Thu, Jun 07, 2018 at 05:42:44PM +0100, Ben Hutchings wrote: > > > > > > > > On 2018-06-04 23:22, Ben Hutchings wrote: > > > > > On Mon, 2018-05-14 at 08:48 +0200, Greg Kroah-Hartman wrote: -> > > > > > 4.4-stable review patch. If anyone has any objections, please let me +> > > > > > 4.4-stable review patch.��If anyone has any objections, please let me� > > > > > > know. > > > > > > > > > > > > ------------------ @@ -31,38 +31,38 @@ On Thu, Jun 07, 2018 at 05:42:44PM +0100, Ben Hutchings wrote: > > > > > [...] > > > > > > > > > > I'm curious as to why this backport doesn't include the change to -> > > > > ath10k_htt_rx_h_find_rfc1042(). I understand that the addition of the +> > > > > ath10k_htt_rx_h_find_rfc1042().��I understand that the addition of the > > > > > new field is a dependency for the following patch, but shouldn't the > > > > > fix included in the upstream commit also be applied to 4.4? > > > > > > > > > -> > > > Our main intention with this patchset [1] was to provide fix for -> > > > replay detection security issue seen in ath10k driver which needed to be +> > > > ���Our main intention with this patchset [1] was to provide fix for� +> > > > replay detection security issue seen in ath10k driver which needed to be� > > > > in the stable releases. > > > > -> > > > And, as per stable tree guidelines we wanted the patchset to have only +> > > > And, as per stable tree guidelines we wanted the patchset to have only� > > > > one and this important fix . > > > > > > OK, I think the problem here is that the rules say "must" when what's -> > > really meant is "should". So the rule "It must fix only one thing." +> > > really meant is "should".��So the rule "It must fix only one thing." > > > really means that commits that each make a single logical change are > > > strongly preferred. > > > > > > It does not mean that upstream commits should be trimmed down to -> > > conform to this. Greg generally considers it more important to avoid -> > > changes to the upstream commit, where possible. Right, Greg? +> > > conform to this.��Greg generally considers it more important to avoid +> > > changes to the upstream commit, where possible.��Right, Greg? > > > > > > And speaking only for myself, I particularly dislike stable backports > > > that are significantly different from the original upstream commit but > > > don't mention this difference in the commit message. > > > > I _STRONGLY_ dislike backports that are different than what is in -> > Linus's tree and normally I catch it when someone tries to do that. I +> > Linus's tree and normally I catch it when someone tries to do that.��I > > missed this one here, and that's not ok on my part for missing that, and > > for the authors part in doing that :( > > > > So, what to do here, should I revert this series and take a fixed-up -> > one? What exactly is the stable tree now missing because of this +> > one?��What exactly is the stable tree now missing because of this > > mistake? > > If you apply the attached patch, that should complete the backporting diff --git a/a/content_digest b/N1/content_digest index 095804f..725a6e3 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -24,7 +24,7 @@ "> > > > \n" "> > > > On 2018-06-04 23:22, Ben Hutchings wrote:\n" "> > > > > On Mon, 2018-05-14 at 08:48 +0200, Greg Kroah-Hartman wrote:\n" - "> > > > > > 4.4-stable review patch.\302\240\302\240If anyone has any objections, please let me\302\240\n" + "> > > > > > 4.4-stable review patch.\303\257\302\277\302\275\303\257\302\277\302\275If anyone has any objections, please let me\303\257\302\277\302\275\n" "> > > > > > know.\n" "> > > > > > \n" "> > > > > > ------------------\n" @@ -49,38 +49,38 @@ "> > > > > [...]\n" "> > > > > \n" "> > > > > I'm curious as to why this backport doesn't include the change to\n" - "> > > > > ath10k_htt_rx_h_find_rfc1042().\302\240\302\240I understand that the addition of the\n" + "> > > > > ath10k_htt_rx_h_find_rfc1042().\303\257\302\277\302\275\303\257\302\277\302\275I understand that the addition of the\n" "> > > > > new field is a dependency for the following patch, but shouldn't the\n" "> > > > > fix included in the upstream commit also be applied to 4.4?\n" "> > > > > \n" "> > > > \n" - "> > > > \302\240\302\240\302\240Our main intention with this patchset [1] was to provide fix for\302\240\n" - "> > > > replay detection security issue seen in ath10k driver which needed to be\302\240\n" + "> > > > \303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275Our main intention with this patchset [1] was to provide fix for\303\257\302\277\302\275\n" + "> > > > replay detection security issue seen in ath10k driver which needed to be\303\257\302\277\302\275\n" "> > > > in the stable releases.\n" "> > > > \n" - "> > > > And, as per stable tree guidelines we wanted the patchset to have only\302\240\n" + "> > > > And, as per stable tree guidelines we wanted the patchset to have only\303\257\302\277\302\275\n" "> > > > one and this important fix .\n" "> > > \n" "> > > OK, I think the problem here is that the rules say \"must\" when what's\n" - "> > > really meant is \"should\".\302\240\302\240So the rule \"It must fix only one thing.\"\n" + "> > > really meant is \"should\".\303\257\302\277\302\275\303\257\302\277\302\275So the rule \"It must fix only one thing.\"\n" "> > > really means that commits that each make a single logical change are\n" "> > > strongly preferred.\n" "> > > \n" "> > > It does not mean that upstream commits should be trimmed down to\n" - "> > > conform to this.\302\240\302\240Greg generally considers it more important to avoid\n" - "> > > changes to the upstream commit, where possible.\302\240\302\240Right, Greg?\n" + "> > > conform to this.\303\257\302\277\302\275\303\257\302\277\302\275Greg generally considers it more important to avoid\n" + "> > > changes to the upstream commit, where possible.\303\257\302\277\302\275\303\257\302\277\302\275Right, Greg?\n" "> > > \n" "> > > And speaking only for myself, I particularly dislike stable backports\n" "> > > that are significantly different from the original upstream commit but\n" "> > > don't mention this difference in the commit message.\n" "> > \n" "> > I _STRONGLY_ dislike backports that are different than what is in\n" - "> > Linus's tree and normally I catch it when someone tries to do that.\302\240\302\240I\n" + "> > Linus's tree and normally I catch it when someone tries to do that.\303\257\302\277\302\275\303\257\302\277\302\275I\n" "> > missed this one here, and that's not ok on my part for missing that, and\n" "> > for the authors part in doing that :(\n" "> > \n" "> > So, what to do here, should I revert this series and take a fixed-up\n" - "> > one?\302\240\302\240What exactly is the stable tree now missing because of this\n" + "> > one?\303\257\302\277\302\275\303\257\302\277\302\275What exactly is the stable tree now missing because of this\n" "> > mistake?\n" "> \n" "> If you apply the attached patch, that should complete the backporting\n" @@ -91,4 +91,4 @@ "\n" greg k-h -c736e72a53bdaa58fe868278b2ef50c5cbff5c36d58119f9701c82eb8ed69666 +2cb8e114291d4451488af877e988b571c010138452be17721d2fba5a7e3b6451
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.