diff for duplicates of <1516820744.3073.30.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 96dd444..67983fe 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,12 +4,12 @@ in the plenary 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 we've been trying to -hold to in SCSI is one review per accepted non-trivial patch. For us, +Filesystems and MM. A The question is should we (or at least should we +adhere to some minimal standards). A The standard we've been trying to +hold to in SCSI is one review per accepted non-trivial patch. 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 certainly think of a couple of bugs I've had to +hasn't gone in. 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 minimum standard across the whole of LSF/MM; it would @@ -20,19 +20,19 @@ certainly serve to improve our Reviewed-by statistics. My observation here is that actually most conflict is generated by the review process (I know, if we increase reviews as I propose in 1. we'll increase conflict on the lists on the basis of this observation), so -I've been thinking about ways to de-escalate it. The principle issue +I've been thinking about ways to de-escalate it. A The principle issue is that a review which doesn't just say the patch is fine (or fine except for nitpicks) can be taken as criticism and criticism is often -processed personally. The way you phrase criticism can have a great +processed personally. A The way you phrase criticism can have a great bearing on the amount of personal insult taken by the other party. - Corny as it sounds, the 0day bot response "Hi Z, I love your patch! +A Corny as it sounds, the 0day bot response "Hi Z,A I love your patch! Perhaps something to improve:" is specifically targetted at this -problem and seems actually to work. I think we could all benefit from +problem and seems actually to work. A I think we could all benefit from discussing how to give and receive criticism in the form of patch reviews responsibly, especially as not everyone's native language in English and certain common linguistic phrasings in other languages can come off as rude when directly translated to English (Russian springs -immediately to mind for some reason here). Also Note, I think fixing +immediately to mind for some reason here). A Also Note, I think fixing the review problem would solve most of the issues, so I'm not proposing anything more formal like the code of conflict stuff in the main kernel. diff --git a/a/content_digest b/N1/content_digest index 40df71e..7571e25 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -13,12 +13,12 @@ "1. Patch Submission Process\n" "\n" "Today we don't have a uniform patch submission process across Storage,\n" - "Filesystems and MM. \302\240The question is should we (or at least should we\n" - "adhere to some minimal standards). \302\240The standard we've been trying to\n" - "hold to in SCSI is one review per accepted non-trivial patch. \302\240For us,\n" + "Filesystems and MM. A The question is should we (or at least should we\n" + "adhere to some minimal standards). A The standard we've been trying to\n" + "hold to in SCSI is one review per accepted non-trivial patch. A For us,\n" "it's useful because it encourages driver writers to review each other's\n" "patches rather than just posting and then complaining their patch\n" - "hasn't gone in. \302\240I can certainly think of a couple of bugs I've had to\n" + "hasn't gone in. A I can certainly think of a couple of bugs I've had to\n" "chase in mm where the underlying patches would have benefited from\n" "review, so I'd like to discuss making the one review per non-trival\n" "patch our base minimum standard across the whole of LSF/MM; it would\n" @@ -29,19 +29,19 @@ "My observation here is that actually most conflict is generated by the\n" "review process (I know, if we increase reviews as I propose in 1. we'll\n" "increase conflict on the lists on the basis of this observation), so\n" - "I've been thinking about ways to de-escalate it. \302\240The principle issue\n" + "I've been thinking about ways to de-escalate it. A The principle issue\n" "is that a review which doesn't just say the patch is fine (or fine\n" "except for nitpicks) can be taken as criticism and criticism is often\n" - "processed personally. \302\240The way you phrase criticism can have a great\n" + "processed personally. A The way you phrase criticism can have a great\n" "bearing on the amount of personal insult taken by the other party.\n" - "\302\240Corny as it sounds, the 0day bot response \"Hi Z,\302\240I love your patch!\n" + "A Corny as it sounds, the 0day bot response \"Hi Z,A I love your patch!\n" "Perhaps something to improve:\" is specifically targetted at this\n" - "problem and seems actually to work. \302\240I think we could all benefit from\n" + "problem and seems actually to work. A I think we could all benefit from\n" "discussing how to give and receive criticism in the form of patch\n" "reviews responsibly, especially as not everyone's native language in\n" "English and certain common linguistic phrasings in other languages can\n" "come off as rude when directly translated to English (Russian springs\n" - "immediately to mind for some reason here). \302\240Also Note, I think fixing\n" + "immediately to mind for some reason here). A Also Note, I think fixing\n" "the review problem would solve most of the issues, so I'm not proposing\n" "anything more formal like the code of conflict stuff in the main\n" "kernel.\n" @@ -58,4 +58,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -3a77099b003f253bc9f24da2ff0e9a320aa159ca8177223fa8f8795556872669 +73a9946c7038e32c90dff2bacd83eb32d8bdd4801b1666fcf0150617a014273b
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.