patch attachments still unwelcome?
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/[email protected]/
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/
Quoted 8 lines · Eric Wong
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).
Quoted 2 lines
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
Quoted 13 lines · Greg KH
Quoted 4 lines
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).
Quoted 2 lines
Are many MUAs still incapable of handling them?
mutt shows text patches inline, at least.
Quoted 8 lines
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
Quoted 24 lines · Theodore Y. Ts'o
Quoted 13 lines · Greg KH
Quoted 4 lines
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).
Quoted 2 lines
Are many MUAs still incapable of handling them?
mutt shows text patches inline, at least.Quoted 8 lines
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.
Quoted 5 lines
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...
Quoted 32 lines · Dmitry Vyukov
Quoted 24 lines · Theodore Y. Ts'o
Quoted 13 lines · Greg KH
Quoted 4 lines
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).
Quoted 2 lines
Are many MUAs still incapable of handling them?
mutt shows text patches inline, at least.Quoted 8 lines
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.
Quoted 5 lines
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.)
Quoted 6 lines
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.
Signature · 1 line
Jani Nikula, Intel Open Source Graphics Center
This is supposed to be inline.
This is supposed to be an attachment.
Hi Jani,
Quoted 5 lines · Jani Nikula
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.
Quoted 8 lines
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
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] 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
Hi Jani,
Quoted 11 lines · Geert Uytterhoeven
Quoted 10 lines · Jani Nikula
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 1 line
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
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] 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
Quoted 23 lines · Theodore Y. Ts'o
Quoted 13 lines · Greg KH
Quoted 4 lines
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).
Quoted 2 lines
Are many MUAs still incapable of handling them?
mutt shows text patches inline, at least.Quoted 8 lines
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.
Quoted 5 lines
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
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.
Quoted 10 lines · Eric Wong
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
Quoted 6 lines · Konstantin Ryabitsev
Quoted 3 lines · Eric Wong
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.
Quoted 8 lines
Quoted 1 line
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.