* patch attachments still unwelcome? @ 2019-11-01 2:27 Eric Wong 2019-11-01 9:04 ` Greg KH 2019-11-01 13:00 ` Konstantin Ryabitsev 0 siblings, 2 replies; 11+ messages in thread From: Eric Wong @ 2019-11-01 2:27 UTC (permalink / raw) To: workflows The BDFL sets an example by attaching patches: https://lore.kernel.org/lkml/?q=f%3Atorvalds+n%3Apatch So the documentation in the kernel advising against sending patch attachments seems hypocritical. Changing the kernel docs allow patch attachments could be a good start to making life easier for contributors without SMTP or IMAP access. Are many MUAs still incapable of handling them? mutt shows text patches inline, at least. I've already been making public-inbox look harder for pre/post-image OIDs in attachments that it wouldn't decode before: https://public-inbox.org/meta/20191031031220.21048-1-e@80x24.org/ And I'm considering making it handle application/octet-stream, too; since patches do end up with the wrong Content-Type, sometimes: https://lore.kernel.org/lkml/CANAwSgRs2DUXwvhJD5qpXg04qEdP_Nt-wQqRbD2FpY2SWnHpAA@mail.gmail.com/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-01 2:27 patch attachments still unwelcome? Eric Wong @ 2019-11-01 9:04 ` Greg KH 2019-11-04 13:13 ` Theodore Y. Ts'o 2019-11-01 13:00 ` Konstantin Ryabitsev 1 sibling, 1 reply; 11+ messages in thread From: Greg KH @ 2019-11-01 9:04 UTC (permalink / raw) To: Eric Wong; +Cc: workflows On Fri, Nov 01, 2019 at 02:27:46AM +0000, Eric Wong wrote: > The BDFL sets an example by attaching patches: > > https://lore.kernel.org/lkml/?q=f%3Atorvalds+n%3Apatch > > So the documentation in the kernel advising against sending > patch attachments seems hypocritical. Changing the kernel docs > allow patch attachments could be a good start to making life > easier for contributors without SMTP or IMAP access. It's not hypocritical, as lots of email clients still get this wrong and make responding to attachments almost impossible. Many do get it right, but trying to document the differences here is quite difficult (I tried once, gave up as it was a mess). > Are many MUAs still incapable of handling them? > mutt shows text patches inline, at least. For most MUAs that send them, yes, but not for all. I know of at least 2 that send text attachments in formats that mutt will not show it inline, nor allow responding to them properly. MacOS Mail is one easy example to point to as getting this totally wrong. So, if you know what you are doing, yes, this is fine, but it's still a good idea to say "please do not do this" to make it easier for people just starting out. thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-01 9:04 ` Greg KH @ 2019-11-04 13:13 ` Theodore Y. Ts'o 2019-11-04 13:23 ` Dmitry Vyukov 2019-11-04 13:42 ` Greg KH 0 siblings, 2 replies; 11+ messages in thread From: Theodore Y. Ts'o @ 2019-11-04 13:13 UTC (permalink / raw) To: Greg KH; +Cc: Eric Wong, workflows On Fri, Nov 01, 2019 at 10:04:56AM +0100, Greg KH wrote: > > So the documentation in the kernel advising against sending > > patch attachments seems hypocritical. Changing the kernel docs > > allow patch attachments could be a good start to making life > > easier for contributors without SMTP or IMAP access. > > It's not hypocritical, as lots of email clients still get this wrong and > make responding to attachments almost impossible. Many do get it right, > but trying to document the differences here is quite difficult (I tried > once, gave up as it was a mess). > > > Are many MUAs still incapable of handling them? > > mutt shows text patches inline, at least. > > For most MUAs that send them, yes, but not for all. I know of at least > 2 that send text attachments in formats that mutt will not show it > inline, nor allow responding to them properly. MacOS Mail is one easy > example to point to as getting this totally wrong. > > So, if you know what you are doing, yes, this is fine, but it's still a > good idea to say "please do not do this" to make it easier for people > just starting out. Perhaps we should explicitly explain this and then include a white list of MUA's that can send text attachments safely/correctly? (e.g., if you are using the following MUA's, using text attachments are OK; if you are using the following MUA's, it will definitely NOT work; with all others, proceed with caution.) - Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-04 13:13 ` Theodore Y. Ts'o @ 2019-11-04 13:23 ` Dmitry Vyukov 2019-11-04 14:49 ` Jani Nikula 2019-11-04 13:42 ` Greg KH 1 sibling, 1 reply; 11+ messages in thread From: Dmitry Vyukov @ 2019-11-04 13:23 UTC (permalink / raw) To: Theodore Y. Ts'o; +Cc: Greg KH, Eric Wong, workflows On Mon, Nov 4, 2019 at 2:13 PM Theodore Y. Ts'o <tytso@mit.edu> wrote: > > On Fri, Nov 01, 2019 at 10:04:56AM +0100, Greg KH wrote: > > > So the documentation in the kernel advising against sending > > > patch attachments seems hypocritical. Changing the kernel docs > > > allow patch attachments could be a good start to making life > > > easier for contributors without SMTP or IMAP access. > > > > It's not hypocritical, as lots of email clients still get this wrong and > > make responding to attachments almost impossible. Many do get it right, > > but trying to document the differences here is quite difficult (I tried > > once, gave up as it was a mess). > > > > > Are many MUAs still incapable of handling them? > > > mutt shows text patches inline, at least. > > > > For most MUAs that send them, yes, but not for all. I know of at least > > 2 that send text attachments in formats that mutt will not show it > > inline, nor allow responding to them properly. MacOS Mail is one easy > > example to point to as getting this totally wrong. > > > > So, if you know what you are doing, yes, this is fine, but it's still a > > good idea to say "please do not do this" to make it easier for people > > just starting out. > > Perhaps we should explicitly explain this and then include a white > list of MUA's that can send text attachments safely/correctly? (e.g., > if you are using the following MUA's, using text attachments are OK; > if you are using the following MUA's, it will definitely NOT work; > with all others, proceed with caution.) One thing that wasn't clear to me when I implemented syzbot is that some people see attachments inline. syzbot included whole kernel config and 1MB of logs as attachments, I assumed that other people see them as, well, attachments. So that may be worth documenting as well. Though, I did not know that document exists as well, so it would not help me... ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-04 13:23 ` Dmitry Vyukov @ 2019-11-04 14:49 ` Jani Nikula 2019-11-04 17:40 ` Geert Uytterhoeven 0 siblings, 1 reply; 11+ messages in thread From: Jani Nikula @ 2019-11-04 14:49 UTC (permalink / raw) To: Dmitry Vyukov, Theodore Y. Ts'o; +Cc: Greg KH, Eric Wong, workflows [-- Attachment #1: Type: text/plain, Size: 2750 bytes --] On Mon, 04 Nov 2019, Dmitry Vyukov <dvyukov@google.com> wrote: > On Mon, Nov 4, 2019 at 2:13 PM Theodore Y. Ts'o <tytso@mit.edu> wrote: >> >> On Fri, Nov 01, 2019 at 10:04:56AM +0100, Greg KH wrote: >> > > So the documentation in the kernel advising against sending >> > > patch attachments seems hypocritical. Changing the kernel docs >> > > allow patch attachments could be a good start to making life >> > > easier for contributors without SMTP or IMAP access. >> > >> > It's not hypocritical, as lots of email clients still get this wrong and >> > make responding to attachments almost impossible. Many do get it right, >> > but trying to document the differences here is quite difficult (I tried >> > once, gave up as it was a mess). >> > >> > > Are many MUAs still incapable of handling them? >> > > mutt shows text patches inline, at least. >> > >> > For most MUAs that send them, yes, but not for all. I know of at least >> > 2 that send text attachments in formats that mutt will not show it >> > inline, nor allow responding to them properly. MacOS Mail is one easy >> > example to point to as getting this totally wrong. >> > >> > So, if you know what you are doing, yes, this is fine, but it's still a >> > good idea to say "please do not do this" to make it easier for people >> > just starting out. >> >> Perhaps we should explicitly explain this and then include a white >> list of MUA's that can send text attachments safely/correctly? (e.g., >> if you are using the following MUA's, using text attachments are OK; >> if you are using the following MUA's, it will definitely NOT work; >> with all others, proceed with caution.) > > > One thing that wasn't clear to me when I implemented syzbot is that > some people see attachments inline. syzbot included whole kernel > config and 1MB of logs as attachments, I assumed that other people see > them as, well, attachments. So that may be worth documenting as well. > Though, I did not know that document exists as well, so it would not > help me... Typically you'd have a multipart/mixed MIME message with several parts of various Content-Types. In this case presumably text/plain, but text/x-diff is not out of the question for patches. Also seen a lot of application/octet-stream for logs. You can give a *hint* to the recipient MUA on how to interpret each part by setting Content-Disposition: attachment or inline. Bottom line, whether you can control that in your MUA, and whether the recipient MUA actually respects that is anyone's guess. For fun, this multipart message contains three parts, the one you're reading, and two additional parts, one of which should be inline and the other one an attachment. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center [-- Attachment #2: inline --] [-- Type: text/plain, Size: 31 bytes --] This is supposed to be inline. [-- Attachment #3: attachment --] [-- Type: text/plain, Size: 38 bytes --] This is supposed to be an attachment. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-04 14:49 ` Jani Nikula @ 2019-11-04 17:40 ` Geert Uytterhoeven 2019-11-05 10:46 ` Geert Uytterhoeven 0 siblings, 1 reply; 11+ messages in thread From: Geert Uytterhoeven @ 2019-11-04 17:40 UTC (permalink / raw) To: Jani Nikula Cc: Dmitry Vyukov, Theodore Y. Ts'o, Greg KH, Eric Wong, workflows Hi Jani, On Mon, Nov 4, 2019 at 3:52 PM Jani Nikula <jani.nikula@intel.com> wrote: > Typically you'd have a multipart/mixed MIME message with several parts > of various Content-Types. In this case presumably text/plain, but > text/x-diff is not out of the question for patches. Also seen a lot of > application/octet-stream for logs. > > You can give a *hint* to the recipient MUA on how to interpret each part > by setting Content-Disposition: attachment or inline. Bottom line, > whether you can control that in your MUA, and whether the recipient MUA > actually respects that is anyone's guess. > > For fun, this multipart message contains three parts, the one you're > reading, and two additional parts, one of which should be inline and the > other one an attachment. So the Gmail web interface shows both as attachments, but can show the contents when I click on them. The Gmail Android app shows both as attachments, and forces me to download the attachments to read them, using a selected app. Ergo, no attachments is the safest. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-04 17:40 ` Geert Uytterhoeven @ 2019-11-05 10:46 ` Geert Uytterhoeven 0 siblings, 0 replies; 11+ messages in thread From: Geert Uytterhoeven @ 2019-11-05 10:46 UTC (permalink / raw) To: Jani Nikula Cc: Dmitry Vyukov, Theodore Y. Ts'o, Greg KH, Eric Wong, workflows Hi Jani, On Mon, Nov 4, 2019 at 6:40 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Mon, Nov 4, 2019 at 3:52 PM Jani Nikula <jani.nikula@intel.com> wrote: > > Typically you'd have a multipart/mixed MIME message with several parts > > of various Content-Types. In this case presumably text/plain, but > > text/x-diff is not out of the question for patches. Also seen a lot of > > application/octet-stream for logs. > > > > You can give a *hint* to the recipient MUA on how to interpret each part > > by setting Content-Disposition: attachment or inline. Bottom line, > > whether you can control that in your MUA, and whether the recipient MUA > > actually respects that is anyone's guess. > > > > For fun, this multipart message contains three parts, the one you're > > reading, and two additional parts, one of which should be inline and the > > other one an attachment. > > So the Gmail web interface shows both as attachments, but can show > the contents when I click on them. > The Gmail Android app shows both as attachments, and forces me to > download the attachments to read them, using a selected app. Just for fun, I tried alpine, which I still use from time to time. Alpine shows the first one "sort of" inline, at the bottom: | -- | Jani Nikula, Intel Open Source Graphics Center | | | [ Part 2: "Attached Text" ] | | This is supposed to be inline. | | | [ Part 3, Text/PLAIN 2 lines. ] | [ Not Shown. Use the "V" command to view or save this part. ] But when replying, the "inline" one is not quoted, so I can't provide review comments. > Ergo, no attachments is the safest. Unless your patches are perfect, and will receive no comments but RoB or AB tags ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-04 13:13 ` Theodore Y. Ts'o 2019-11-04 13:23 ` Dmitry Vyukov @ 2019-11-04 13:42 ` Greg KH 2019-11-04 13:42 ` Drew DeVault 1 sibling, 1 reply; 11+ messages in thread From: Greg KH @ 2019-11-04 13:42 UTC (permalink / raw) To: Theodore Y. Ts'o; +Cc: Eric Wong, workflows On Mon, Nov 04, 2019 at 08:13:10AM -0500, Theodore Y. Ts'o wrote: > On Fri, Nov 01, 2019 at 10:04:56AM +0100, Greg KH wrote: > > > So the documentation in the kernel advising against sending > > > patch attachments seems hypocritical. Changing the kernel docs > > > allow patch attachments could be a good start to making life > > > easier for contributors without SMTP or IMAP access. > > > > It's not hypocritical, as lots of email clients still get this wrong and > > make responding to attachments almost impossible. Many do get it right, > > but trying to document the differences here is quite difficult (I tried > > once, gave up as it was a mess). > > > > > Are many MUAs still incapable of handling them? > > > mutt shows text patches inline, at least. > > > > For most MUAs that send them, yes, but not for all. I know of at least > > 2 that send text attachments in formats that mutt will not show it > > inline, nor allow responding to them properly. MacOS Mail is one easy > > example to point to as getting this totally wrong. > > > > So, if you know what you are doing, yes, this is fine, but it's still a > > good idea to say "please do not do this" to make it easier for people > > just starting out. > > Perhaps we should explicitly explain this and then include a white > list of MUA's that can send text attachments safely/correctly? (e.g., > if you are using the following MUA's, using text attachments are OK; > if you are using the following MUA's, it will definitely NOT work; > with all others, proceed with caution.) I'm not going to try to keep such a list up-to-date, that's crazy. It usually depends on defaults/configurations as well, so it's not always the specific program. Also different versions do different things (like Mail from OS-X). So it's just much easier to say, "no attachments" and then if you really know what you are doing, and you know your email client will set it up properly, then do it. Also, Zoho mail, ugh, I never understood how that could always send stuff out so horribly... greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-04 13:42 ` Greg KH @ 2019-11-04 13:42 ` Drew DeVault 0 siblings, 0 replies; 11+ messages in thread From: Drew DeVault @ 2019-11-04 13:42 UTC (permalink / raw) To: Greg KH, Theodore Y. Ts'o; +Cc: Eric Wong, workflows Also pitching in with a vote against patches-as-attachments. My mailing list software doesn't know how to deal with these and I don't really want to teach it about them. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-01 2:27 patch attachments still unwelcome? Eric Wong 2019-11-01 9:04 ` Greg KH @ 2019-11-01 13:00 ` Konstantin Ryabitsev 2019-11-04 11:26 ` Mark Brown 1 sibling, 1 reply; 11+ messages in thread From: Konstantin Ryabitsev @ 2019-11-01 13:00 UTC (permalink / raw) To: Eric Wong; +Cc: workflows On Fri, Nov 01, 2019 at 02:27:46AM +0000, Eric Wong wrote: > The BDFL sets an example by attaching patches: > > https://lore.kernel.org/lkml/?q=f%3Atorvalds+n%3Apatch > > So the documentation in the kernel advising against sending > patch attachments seems hypocritical. Changing the kernel docs > allow patch attachments could be a good start to making life > easier for contributors without SMTP or IMAP access. > > Are many MUAs still incapable of handling them? It's not really that they are incapable of "handling" them, it's that patches-as-attachments make it significantly harder to do code review in a way that is convenient to developers. While some MUAs will properly inline-quote an attached text/plain file when you hit "Reply All", many others won't, requiring manual copy-pasting in order to comment on actual patch contents. -K ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch attachments still unwelcome? 2019-11-01 13:00 ` Konstantin Ryabitsev @ 2019-11-04 11:26 ` Mark Brown 0 siblings, 0 replies; 11+ messages in thread From: Mark Brown @ 2019-11-04 11:26 UTC (permalink / raw) To: Eric Wong, workflows [-- Attachment #1: Type: text/plain, Size: 871 bytes --] On Fri, Nov 01, 2019 at 09:00:12AM -0400, Konstantin Ryabitsev wrote: > On Fri, Nov 01, 2019 at 02:27:46AM +0000, Eric Wong wrote: > > patch attachments seems hypocritical. Changing the kernel docs > > allow patch attachments could be a good start to making life > > easier for contributors without SMTP or IMAP access. > > Are many MUAs still incapable of handling them? > It's not really that they are incapable of "handling" them, it's that > patches-as-attachments make it significantly harder to do code review in > a way that is convenient to developers. While some MUAs will properly > inline-quote an attached text/plain file when you hit "Reply All", > many others won't, requiring manual copy-pasting in order to comment on > actual patch contents. It's not just the recieving end either - persuading some MTAs to encode things as text can be a challenge. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-11-05 10:46 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-01 2:27 patch attachments still unwelcome? Eric Wong 2019-11-01 9:04 ` Greg KH 2019-11-04 13:13 ` Theodore Y. Ts'o 2019-11-04 13:23 ` Dmitry Vyukov 2019-11-04 14:49 ` Jani Nikula 2019-11-04 17:40 ` Geert Uytterhoeven 2019-11-05 10:46 ` Geert Uytterhoeven 2019-11-04 13:42 ` Greg KH 2019-11-04 13:42 ` Drew DeVault 2019-11-01 13:00 ` Konstantin Ryabitsev 2019-11-04 11:26 ` Mark Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).