docs: submitting-patches: Discuss interleaved replies
Subsystems (2)
PATCH 1/1 docs: submitting-patches: Discuss interleaved replies
Top-posting has been strongly discouraged in Linux development, but this was actually not written anywhere in the common documentation about sending patches and replying to reviews. Add a section about trimming and interleaved replies.
--- Documentation/process/submitting-patches.rst | 23 ++++++++++++++++++++ 1 file changed, 23 insertions(+)
Documentation/process/submitting-patches.rst +23 -0
@@ -326,6 +326,29 @@ explaining difference aganst previous submission (see See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette. +Use trimmed interleaved replies in email discussions +---------------------------------------------------- +Top-posting is strongly discouraged in Linux kernel development +discusions. Interleaved (or "inline") replies make conversations much +easier to follow. For more details see: +https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +As is frequently quoted on the mailing list: + + A: http://en.wikipedia.org/wiki/Top_post + Q: Were do I find info about this thing called top-posting? + A: Because it messes up the order in which people normally read text. + Q: Why is top-posting such a bad thing? + A: Top-posting. + Q: What is the most annoying thing in e-mail? + +Similarly, please trim all unneeded quotations that aren't relevant +to your reply. This makes replies easier to find, and saves time and +space. For more details see: http://daringfireball.net/2007/07/on_top + + A: No. + Q: Should I include quotations after my reply? + .. _resend_reminders: Don't get discouraged - or impatient
Signature · 1 line
2.34.1
Quoted 55 lines · Kees Cook
Top-posting has been strongly discouraged in Linux development, but this was actually not written anywhere in the common documentation about sending patches and replying to reviews. Add a section about trimming and interleaved replies.
Cc Jonathan Corbet <[email protected]>Cc Greg Kroah-Hartman <[email protected]>Cc Thorsten Leemhuis <[email protected]>Cc Rong Tao <[email protected]>Cc Lukas Bulwahn <[email protected]>Cc Zhangfei Gao <[email protected]>Signed-off-by Kees Cook <[email protected]>--- Documentation/process/submitting-patches.rst | 23 ++++++++++++++++++++ 1 file changed, 23 insertions(+)Documentation/process/submitting-patches.rst +23
-0@@ -326,6 +326,29 @@ explaining difference aganst previous submission (see See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette. +Use trimmed interleaved replies in email discussions +---------------------------------------------------- +Top-posting is strongly discouraged in Linux kernel development +discusions. Interleaved (or "inline") replies make conversations much +easier to follow. For more details see: +https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +As is frequently quoted on the mailing list: + + A: http://en.wikipedia.org/wiki/Top_post + Q: Were do I find info about this thing called top-posting? + A: Because it messes up the order in which people normally read text. + Q: Why is top-posting such a bad thing? + A: Top-posting. + Q: What is the most annoying thing in e-mail? + +Similarly, please trim all unneeded quotations that aren't relevant +to your reply. This makes replies easier to find, and saves time and +space. For more details see: http://daringfireball.net/2007/07/on_top + + A: No. + Q: Should I include quotations after my reply? + .. _resend_reminders: Don't get discouraged - or impatientSignature · 1 line
2.34.1
Yes!!!
Quoted 4 lines · Kees Cook
Top-posting has been strongly discouraged in Linux development, but this was actually not written anywhere in the common documentation about sending patches and replying to reviews. Add a section about trimming and interleaved replies.
Thx for doing this.
Quoted 4 lines
[...]
--- Documentation/process/submitting-patches.rst | 23 ++++++++++++++++++++ 1 file changed, 23 insertions(+)
For some reason we have duplicate code^w documentation for this, hence I'd say the same or a similar text should also be added to one of the filed in Documentation/process/[0-9].*rst ; from a quick Documentation/process/6.Followthrough.rst might be the best one.
Maybe in fact the text should move there and submitting-patches.rst should have a much shorter version, as it's meant to be the terser of the two docs about this.
Documentation/process/submitting-patches.rst explaining difference aganst previous submission (see · line 332
Quoted 12 lines
Documentation/process/submitting-patches.rst +4
-0@@ -326,6 +326,29 @@ explaining difference aganst previous submission (see See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette. +Use trimmed interleaved replies in email discussions +---------------------------------------------------- +Top-posting is strongly discouraged in Linux kernel development +discusions. Interleaved (or "inline") replies make conversations much
s/discusions/discussions/
Quoted 4 lines
Documentation/process/submitting-patches.rst +4
-0+easier to follow. For more details see: +https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +As is frequently quoted on the mailing list:
Documentation/process/submitting-patches.rst explaining difference aganst previous submission (see · line 346
Quoted 10 lines
Documentation/process/submitting-patches.rst +10
-0+ + A: http://en.wikipedia.org/wiki/Top_post + Q: Were do I find info about this thing called top-posting? + A: Because it messes up the order in which people normally read text. + Q: Why is top-posting such a bad thing? + A: Top-posting. + Q: What is the most annoying thing in e-mail? + +Similarly, please trim all unneeded quotations that aren't relevant +to your reply. This makes replies easier to find, and saves time and
Nitpicking, feel free to ignore: maybe "s/replies/responses/" or something like that, as at least my stupid brain accidentally thought of the email reply (as whole) when reading this for the first time.
Documentation/process/submitting-patches.rst explaining difference aganst previous submission (see · line 347
Quoted 2 lines
Documentation/process/submitting-patches.rst +1
-0+space. For more details see: http://daringfireball.net/2007/07/on_top
Ciao, Thorsten
Quoted 13 lines · Thorsten Leemhuis
Quoted 4 lines · Kees Cook
Top-posting has been strongly discouraged in Linux development, but this was actually not written anywhere in the common documentation about sending patches and replying to reviews. Add a section about trimming and interleaved replies.
Thx for doing this.
Quoted 4 lines
[...]
--- Documentation/process/submitting-patches.rst | 23 ++++++++++++++++++++ 1 file changed, 23 insertions(+)
Quoted 8 lines
For some reason we have duplicate code^w documentation for this, hence I'd say the same or a similar text should also be added to one of the filed in Documentation/process/[0-9].*rst ; from a quick
Documentation/process/6.Followthrough.rstmight be the best one.Maybe in fact the text should move there and
submitting-patches.rstshould have a much shorter version, as it's meant to be the terser of the two docs about this.
Hm, The place where it is mentioned is even shorter, so I kind of like it in submittingpatches. But, I'm open to whatever seems best. I just want to have a URL to point people at, and I'm usually pointing to places in submittingpatches. :)
Quoted 9 lines
Quoted 9 lines
Documentation/process/submitting-patches.rst +0
-0@@ -326,6 +326,29 @@ explaining difference aganst previous submission (see See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette.
Quoted 6 lines
Documentation/process/submitting-patches.rst explaining difference aganst previous submission (see · line 332
Quoted 4 lines
Documentation/process/submitting-patches.rst +4
-0+Use trimmed interleaved replies in email discussions +---------------------------------------------------- +Top-posting is strongly discouraged in Linux kernel development +discusions. Interleaved (or "inline") replies make conversations muchs/discusions/discussions/
Agh, thanks. Fixed.
Quoted 11 lines
Quoted 11 lines
Documentation/process/submitting-patches.rst +10
-0+easier to follow. For more details see: +https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +As is frequently quoted on the mailing list: + + A: http://en.wikipedia.org/wiki/Top_post + Q: Were do I find info about this thing called top-posting? + A: Because it messes up the order in which people normally read text. + Q: Why is top-posting such a bad thing? + A: Top-posting.
Quoted 8 lines
Documentation/process/submitting-patches.rst explaining difference aganst previous submission (see · line 346
Quoted 4 lines
Documentation/process/submitting-patches.rst +4
-0+ Q: What is the most annoying thing in e-mail? + +Similarly, please trim all unneeded quotations that aren't relevant +to your reply. This makes replies easier to find, and saves time andNitpicking, feel free to ignore: maybe "s/replies/responses/" or something like that, as at least my stupid brain accidentally thought of the email reply (as whole) when reading this for the first time.
Yeah, that is more readable. Fixed.
Quoted 4 lines
Documentation/process/submitting-patches.rst explaining difference aganst previous submission (see · line 347
Quoted 2 lines
Documentation/process/submitting-patches.rst +1
-0+space. For more details see: http://daringfireball.net/2007/07/on_topCiao, Thorsten
Thanks!
Signature · 1 line
Kees Cook
Quoted 19 lines · Kees Cook
Quoted 18 lines · Thorsten Leemhuis
Quoted 4 lines · Kees Cook
Top-posting has been strongly discouraged in Linux development, but this was actually not written anywhere in the common documentation about sending patches and replying to reviews. Add a section about trimming and interleaved replies.
Thx for doing this.
Quoted 4 lines
[...]
--- Documentation/process/submitting-patches.rst | 23 ++++++++++++++++++++ 1 file changed, 23 insertions(+)For some reason we have duplicate code^w documentation for this, hence I'd say the same or a similar text should also be added to one of the filed in Documentation/process/[0-9].*rst ; from a quick
Documentation/process/6.Followthrough.rstmight be the best one.
Quoted 5 lines
Quoted 3 lines
Maybe in fact the text should move there and
submitting-patches.rstshould have a much shorter version, as it's meant to be the terser of the two docs about this.Hm, The place where it is mentioned is even shorter,
Ohh, it is mentioned there already? I briefly looked, but had missed it. Sorry. :-/
Quoted 2 lines
so I kind of like
it in submittingpatches. But, I'm open to whatever seems best.
Guess that is Jonathan's call to make. Your v2 patch to me looks a bit like adding quite a bit of new and slow code to the fast path while adjusting faster code in the slow path.
But the relation and interaction between those two texts in a bit messy already, so maybe it doesn't matter that much.
Ciao, Thorsten