diff for duplicates of <20180124234347.GA11926@magnolia> diff --git a/a/1.txt b/N1/1.txt index 02e7d99..4d7851a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -9,12 +9,12 @@ On Wed, Jan 24, 2018 at 01:36:00PM -0800, James Bottomley 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.��The question is should we (or at +> > > least should we adhere to some minimal standards).��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.��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.��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 @@ -26,7 +26,7 @@ On Wed, Jan 24, 2018 at 01:36:00PM -0800, James Bottomley 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. �Michal did say that XFS didn't have the > problem, however there not being XFS people in the room, discussion > stopped there. @@ -104,7 +104,7 @@ in. Unfortunately, I'm not sufficiently familiar with the mm community to know if I've just asked for the moon. That's where LSFMM comes in. :) -> Having this as a plenary would allow people outside mm +>�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. diff --git a/a/content_digest b/N1/content_digest index aeac07c..58b9a1d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -23,12 +23,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.\303\257\302\277\302\275\303\257\302\277\302\275The question is should we (or at\n" + "> > > least should we adhere to some minimal standards).\303\257\302\277\302\275\303\257\302\277\302\275The 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.\303\257\302\277\302\275\303\257\302\277\302\275For 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.\303\257\302\277\302\275\303\257\302\277\302\275I 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" @@ -40,7 +40,7 @@ "> \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. \303\257\302\277\302\275Michal did say that XFS didn't have the\n" "> problem, however there not being XFS people in the room, discussion\n" "> stopped there.\n" "\n" @@ -118,7 +118,7 @@ "Unfortunately, I'm not sufficiently familiar with the mm community to\n" "know if I've just asked for the moon. That's where LSFMM comes in. :)\n" "\n" - ">\302\240Having this as a plenary would allow people outside mm\n" + ">\303\257\302\277\302\275Having 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" @@ -136,4 +136,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -da12ffcbb974e8c2196b859893d398a8ae245edc621237d7ffb15f2b3f067d20 +9b962592ac594e5a36a6b68d309c2f062cc94dee24ba7fa1eb2f9ca369b92eed
diff --git a/a/1.txt b/N2/1.txt index 02e7d99..fcd6130 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -9,12 +9,12 @@ On Wed, Jan 24, 2018 at 01:36:00PM -0800, James Bottomley 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. The question is should we (or at +> > > least should we adhere to some minimal standards). 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. 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. 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 @@ -26,7 +26,7 @@ On Wed, Jan 24, 2018 at 01:36:00PM -0800, James Bottomley 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. Michal did say that XFS didn't have the > problem, however there not being XFS people in the room, discussion > stopped there. @@ -104,7 +104,7 @@ in. Unfortunately, I'm not sufficiently familiar with the mm community to know if I've just asked for the moon. That's where LSFMM comes in. :) -> Having this as a plenary would allow people outside mm +> 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. diff --git a/a/content_digest b/N2/content_digest index aeac07c..92dc78a 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -23,12 +23,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. The question is should we (or at\n" + "> > > least should we adhere to some minimal standards). 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. 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. 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" @@ -40,7 +40,7 @@ "> \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. Michal did say that XFS didn't have the\n" "> problem, however there not being XFS people in the room, discussion\n" "> stopped there.\n" "\n" @@ -118,7 +118,7 @@ "Unfortunately, I'm not sufficiently familiar with the mm community to\n" "know if I've just asked for the moon. That's where LSFMM comes in. :)\n" "\n" - ">\302\240Having this as a plenary would allow people outside mm\n" + "> 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" @@ -136,4 +136,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -da12ffcbb974e8c2196b859893d398a8ae245edc621237d7ffb15f2b3f067d20 +b5e45216c02aa68f8ac9676a3defec0076c19ea8bacc8b0cd35bb215d86ed3a7
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.