Workflows Archive on lore.kernel.org
 help / color / Atom feed
* 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  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

* 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: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-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

end of thread, back to index

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

Workflows Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/workflows/0 workflows/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 workflows workflows/ https://lore.kernel.org/workflows \
		workflows@vger.kernel.org
	public-inbox-index workflows

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.workflows


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git