All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1516829760.3073.43.camel@HansenPartnership.com>

diff --git a/a/1.txt b/N1/1.txt
index 2624950..5ad1834 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -32,3 +32,9 @@ to describe their experiences and for us to look at process based
 solutions using our shared experience.
 
 James
+
+--
+To unsubscribe, send a message with 'unsubscribe linux-mm' in
+the body to majordomo@kvack.org.  For more info on Linux MM,
+see: http://www.linux-mm.org/ .
+Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
diff --git a/a/content_digest b/N1/content_digest
index 7382de1..c66999f 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -43,6 +43,12 @@
  "to describe their experiences and for us to look at process based\n"
  "solutions using our shared experience.\n"
  "\n"
- James
+ "James\n"
+ "\n"
+ "--\n"
+ "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n"
+ "the body to majordomo@kvack.org.  For more info on Linux MM,\n"
+ "see: http://www.linux-mm.org/ .\n"
+ "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
 
-96c1632fcf3f9ca971d550cf8d4e5fdd2187c54175e5058233a1390a01c468e1
+51847598eacdd9b922ead3fad68e5a40dea5c38863a0119a611643b6d4e0993c

diff --git a/a/1.txt b/N2/1.txt
index 2624950..e812cf2 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -8,12 +8,12 @@ On Wed, 2018-01-24 at 11:20 -0800, Mike Kravetz wrote:
 > > 1. Patch Submission Process
 > > 
 > > Today we don't have a uniform patch submission process across
-> > Storage, Filesystems and MM.  The question is should we (or at
-> > least should we adhere to some minimal standards).  The standard
+> > Storage, Filesystems and MM.A A The question is should we (or at
+> > least should we adhere to some minimal standards).A A The standard
 > > we've been trying to hold to in SCSI is one review per accepted
-> > non-trivial patch.  For us, it's useful because it encourages
+> > non-trivial patch.A A For us, it's useful because it encourages
 > > driver writers to review each other's patches rather than just
-> > posting and then complaining their patch hasn't gone in.  I can
+> > posting and then complaining their patch hasn't gone in.A A I can
 > > certainly think of a couple of bugs I've had to chase in mm where
 > > the underlying patches would have benefited from review, so I'd
 > > like to discuss making the one review per non-trival patch our base
@@ -25,10 +25,16 @@ On Wed, 2018-01-24 at 11:20 -0800, Mike Kravetz wrote:
 
 The pushback in your session was mandating reviews would mean slowing
 patch acceptance or possibly causing the dropping of patches that
-couldn't get reviewed.  Michal did say that XFS didn't have the
+couldn't get reviewed. A Michal did say that XFS didn't have the
 problem, however there not being XFS people in the room, discussion
-stopped there.  Having this as a plenary would allow people outside mm
+stopped there. A Having this as a plenary would allow people outside mm
 to describe their experiences and for us to look at process based
 solutions using our shared experience.
 
 James
+
+--
+To unsubscribe, send a message with 'unsubscribe linux-mm' in
+the body to majordomo@kvack.org.  For more info on Linux MM,
+see: http://www.linux-mm.org/ .
+Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
diff --git a/a/content_digest b/N2/content_digest
index 7382de1..67a9059 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -20,12 +20,12 @@
  "> > 1. Patch Submission Process\n"
  "> > \n"
  "> > Today we don't have a uniform patch submission process across\n"
- "> > Storage, Filesystems and MM.\302\240\302\240The question is should we (or at\n"
- "> > least should we adhere to some minimal standards).\302\240\302\240The standard\n"
+ "> > Storage, Filesystems and MM.A A The question is should we (or at\n"
+ "> > least should we adhere to some minimal standards).A A The standard\n"
  "> > we've been trying to hold to in SCSI is one review per accepted\n"
- "> > non-trivial patch.\302\240\302\240For us, it's useful because it encourages\n"
+ "> > non-trivial patch.A A For us, it's useful because it encourages\n"
  "> > driver writers to review each other's patches rather than just\n"
- "> > posting and then complaining their patch hasn't gone in.\302\240\302\240I can\n"
+ "> > posting and then complaining their patch hasn't gone in.A A I can\n"
  "> > certainly think of a couple of bugs I've had to chase in mm where\n"
  "> > the underlying patches would have benefited from review, so I'd\n"
  "> > like to discuss making the one review per non-trival patch our base\n"
@@ -37,12 +37,18 @@
  "\n"
  "The pushback in your session was mandating reviews would mean slowing\n"
  "patch acceptance or possibly causing the dropping of patches that\n"
- "couldn't get reviewed. \302\240Michal did say that XFS didn't have the\n"
+ "couldn't get reviewed. A Michal did say that XFS didn't have the\n"
  "problem, however there not being XFS people in the room, discussion\n"
- "stopped there. \302\240Having this as a plenary would allow people outside mm\n"
+ "stopped there. A Having this as a plenary would allow people outside mm\n"
  "to describe their experiences and for us to look at process based\n"
  "solutions using our shared experience.\n"
  "\n"
- James
+ "James\n"
+ "\n"
+ "--\n"
+ "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n"
+ "the body to majordomo@kvack.org.  For more info on Linux MM,\n"
+ "see: http://www.linux-mm.org/ .\n"
+ "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
 
-96c1632fcf3f9ca971d550cf8d4e5fdd2187c54175e5058233a1390a01c468e1
+5a74c78a53446bceaf81ff4f36a38abd666bb6ff6814ec5c420eeda2f12d7eef

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.