diff for duplicates of <CAMP44s2Un-M2OCmuRQGpGsHR21gH=S7oJKx4Ci8tvYVCCSitUw@mail.gmail.com>
diff --git a/a/1.txt b/N1/1.txt
index c3e3146..497b14c 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -15,11 +15,11 @@ On Sat, Apr 14, 2012 at 10:41 AM, Stefan Richter
> Huh?
>
> Because "yesterday" was a review before stable release:
-> - A buggy mainline release exists.
-> - No buggy stable release exists.
+> ?- A buggy mainline release exists.
+> ?- No buggy stable release exists.
> whereas "today" is after stable release:
-> - A buggy mainline release exists.
-> - A buggy stable release exists.
+> ?- A buggy mainline release exists.
+> ?- A buggy stable release exists.
IOW; a tag makes undroppable.
@@ -43,28 +43,28 @@ shift in priorities.
>> Again, you can repeat the same thing as much as you want, it still
>> doesn't answer what I have asked.
>
-> Yeah, sorry for that. All the time I thought you asked why a *revert*
+> Yeah, sorry for that. ?All the time I thought you asked why a *revert*
> which is applicable to mainline and stable first happens in stable.
>
> But your question was actually what the difference between
-> - dropping a patch from a queue of candidate patches versus
-> - adding a reverting patch to repair a defect from a previous release
+> ?- dropping a patch from a queue of candidate patches versus
+> ?- adding a reverting patch to repair a defect from a previous release
> is.
Yes, that is one of my arguments.
> The former is still part of the decision whether a changeset which
-> exists in mainline should be backported into stable. Somebody initially
+> exists in mainline should be backported into stable. ?Somebody initially
> thought it should be, but others should have a look too and amend that
-> decision if need be. Somebody reports that the change would introduce a
-> regression. Usually, this disqualifies a patch from being applied to
+> decision if need be. ?Somebody reports that the change would introduce a
+> regression. ?Usually, this disqualifies a patch from being applied to
> stable right away, without further work having to be done in stable.
>
> "Drop a stable candidate before release" is a form of "decline a
> submission to stable", happening late in the preparations of a stable
> release.
>
-> The latter is when damage was done; it is now about bug fixing. This
+> The latter is when damage was done; it is now about bug fixing. ?This
> involves debugging of the regression, finding a right approach to
> fix it (e.g. revert), write + review + test + commit the fix, port the fix
> to all relevant other kernel branches, review + test + commit those ports
@@ -89,12 +89,12 @@ in mainline.
> "Add a reverting fix" is a form of "add a fix".
>
-> You are indeed pointing to a procedural flaw here. In "add a fix" cases,
+> You are indeed pointing to a procedural flaw here. ?In "add a fix" cases,
> stable release procedures ensure that if 3.3.3 included the revert, 3.4
> will include it to, by the Linus->Greg order of commiting patches. But in
> the "drop a candidate before release" case, Greg and the stable reviewers
> do not have a similarly fool-proof procedure to ensure that the next branch
-> point will be free of the regression. Now they need to watch closely that
+> point will be free of the regression. ?Now they need to watch closely that
> a fix gets into mainline ideally before the next branch point is going to
> be released.
@@ -119,7 +119,7 @@ Seems to me you are abusing the 'stable' branch as a bug tracking
system for certain patches for the next release.
> So there is indeed a difficulty involved with dropping patches from the
-> candidate queue. Fortunately, it is not necessary to subject post-release
+> candidate queue. ?Fortunately, it is not necessary to subject post-release
> reverts to the same difficulty.
It's the other way around.
diff --git a/a/content_digest b/N1/content_digest
index 26a09be..b13da70 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -47,27 +47,13 @@
"From\0Felipe Contreras <felipe.contreras\@gmail.com>\0"
]
[
- "Subject\0Re: [ 00/78] 3.3.2-stable review\0"
+ "Subject\0[ath9k-devel] [ 00/78] 3.3.2-stable review\0"
]
[
"Date\0Sat, 14 Apr 2012 18:29:54 +0300\0"
]
[
- "To\0Stefan Richter <stefanr\@s5r6.in-berlin.de>\0"
-]
-[
- "Cc\0Adrian Chadd <adrian\@freebsd.org>",
- " Greg KH <gregkh\@linuxfoundation.org>",
- " Sergio Correia <lists\@uece.net>",
- " linux-kernel\@vger.kernel.org",
- " stable\@vger.kernel.org",
- " torvalds\@linux-foundation.org",
- " akpm\@linux-foundation.org",
- " alan\@lxorguk.ukuu.org.uk",
- " linux-wireless Mailing List <linux-wireless\@vger.kernel.org>",
- " Sujith Manoharan <c_manoha\@qca.qualcomm.com>",
- " ath9k-devel\@lists.ath9k.org <ath9k-devel\@venema.h4ckr.net>",
- " John W. Linville <linville\@tuxdriver.com>\0"
+ "To\0ath9k-devel\@lists.ath9k.org\0"
]
[
"\0000:1\0"
@@ -93,11 +79,11 @@
"> Huh?\n",
">\n",
"> Because \"yesterday\" was a review before stable release:\n",
- "> \302\240- A buggy mainline release exists.\n",
- "> \302\240- No buggy stable release exists.\n",
+ "> ?- A buggy mainline release exists.\n",
+ "> ?- No buggy stable release exists.\n",
"> whereas \"today\" is after stable release:\n",
- "> \302\240- A buggy mainline release exists.\n",
- "> \302\240- A buggy stable release exists.\n",
+ "> ?- A buggy mainline release exists.\n",
+ "> ?- A buggy stable release exists.\n",
"\n",
"IOW; a tag makes undroppable.\n",
"\n",
@@ -121,28 +107,28 @@
">> Again, you can repeat the same thing as much as you want, it still\n",
">> doesn't answer what I have asked.\n",
">\n",
- "> Yeah, sorry for that. \302\240All the time I thought you asked why a *revert*\n",
+ "> Yeah, sorry for that. ?All the time I thought you asked why a *revert*\n",
"> which is applicable to mainline and stable first happens in stable.\n",
">\n",
"> But your question was actually what the difference between\n",
- "> \302\240- dropping a patch from a queue of candidate patches versus\n",
- "> \302\240- adding a reverting patch to repair a defect from a previous release\n",
+ "> ?- dropping a patch from a queue of candidate patches versus\n",
+ "> ?- adding a reverting patch to repair a defect from a previous release\n",
"> is.\n",
"\n",
"Yes, that is one of my arguments.\n",
"\n",
"> The former is still part of the decision whether a changeset which\n",
- "> exists in mainline should be backported into stable. \302\240Somebody initially\n",
+ "> exists in mainline should be backported into stable. ?Somebody initially\n",
"> thought it should be, but others should have a look too and amend that\n",
- "> decision if need be. \302\240Somebody reports that the change would introduce a\n",
- "> regression. \302\240Usually, this disqualifies a patch from being applied to\n",
+ "> decision if need be. ?Somebody reports that the change would introduce a\n",
+ "> regression. ?Usually, this disqualifies a patch from being applied to\n",
"> stable right away, without further work having to be done in stable.\n",
">\n",
"> \"Drop a stable candidate before release\" is a form of \"decline a\n",
"> submission to stable\", happening late in the preparations of a stable\n",
"> release.\n",
">\n",
- "> The latter is when damage was done; it is now about bug fixing. \302\240This\n",
+ "> The latter is when damage was done; it is now about bug fixing. ?This\n",
"> involves debugging of the regression, finding a right approach to\n",
"> fix it (e.g. revert), write + review + test + commit the fix, port the fix\n",
"> to all relevant other kernel branches, review + test + commit those ports\n",
@@ -167,12 +153,12 @@
"\n",
"> \"Add a reverting fix\" is a form of \"add a fix\".\n",
">\n",
- "> You are indeed pointing to a procedural flaw here. \302\240In \"add a fix\" cases,\n",
+ "> You are indeed pointing to a procedural flaw here. ?In \"add a fix\" cases,\n",
"> stable release procedures ensure that if 3.3.3 included the revert, 3.4\n",
"> will include it to, by the Linus->Greg order of commiting patches. But in\n",
"> the \"drop a candidate before release\" case, Greg and the stable reviewers\n",
"> do not have a similarly fool-proof procedure to ensure that the next branch\n",
- "> point will be free of the regression. \302\240Now they need to watch closely that\n",
+ "> point will be free of the regression. ?Now they need to watch closely that\n",
"> a fix gets into mainline ideally before the next branch point is going to\n",
"> be released.\n",
"\n",
@@ -197,7 +183,7 @@
"system for certain patches for the next release.\n",
"\n",
"> So there is indeed a difficulty involved with dropping patches from the\n",
- "> candidate queue. \302\240Fortunately, it is not necessary to subject post-release\n",
+ "> candidate queue. ?Fortunately, it is not necessary to subject post-release\n",
"> reverts to the same difficulty.\n",
"\n",
"It's the other way around.\n",
@@ -206,4 +192,4 @@
"Felipe Contreras"
]
-01f5712eb80f3662f5d28f034572405fb82e9b1acc6c91018195055310f42dc2
+d0996903b97fd2fc2b13a868d95bc610a019d77113a1cc0ff5505ba2e02413e5
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.