Re: RFE: use patchwork to submit a patch

[Dmitry Vyukov <dvyukov@google.com>]

On Sat, Nov 9, 2019 at 5:31 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Fri, Nov 08, 2019 at 03:25:00PM +0100, Dmitry Vyukov wrote:
> >
> > It has the format=flowed; delsp=yes part:
> >
> > Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes
> >
> > Which according to https://tools.ietf.org/html/rfc3676 seems to mean
> > that that line is not wrapped: new line and 1 space needs to be
> > removed as part of decoding it.
>
> Actually if you read RFC 3676 carefully, the receiver MAY decode as
> you have described above.  It's not even a SHOULD or a MUST.
>
> Essentially format=flowed is only supposed to be used when it's
> considered OK for the receiver to reflow (or not) the lines any darned
> way it wants.
>
> If you use format=flowed in a context where (a) there might be
> whitespace at the end of lines, and random reflowing is a really bad
> idea (e.g., C/C++/Python/Java source files, or patches), or (b) where
> you really care about whether line breaks when text is quoted and used
> in replies (e.g., syzbot's parser which cares about line breaks), you
> MUST NOT use format=flowed, or things will only end in tears.

You are right.
syzbot email only MAY be correct :)
But for me the point re email still stands: why are we even spending
time discussing this? Why are there such extensions with MAY status?
If one doesn't care if the received with recover the original message
or not, why caring adding/specifying these "format=flowed;
delsp=yes"?...
Obviously somebody in the middle got confused about these flowed/delsp
as well and either assumed that they are MUST or assumed that
preserving precise text for emails is just never important...

> If the problem here is that syzbot mail, and the responses to its
> mails, can't be broken in random places, or syzbot parser will be
> unhappy.  In that case, you shouldn't have sent it using format=flowed
> in the first place.  There are other MIME text formats that are
> appropriate in that particular case, but format=flowed is not one of
> them.  And if GMail doesn't give you that option, then I suggest that
> you either make the Syzbot parser more forgiving, or you find another
> mail transport agent.

I don't see how it's possible to make it more forgiving without also
appending unrelated text that happened to be on subsequent lines to
patch titles and breaking everything the other way.
I added one partial escape hatch in the form of:

#syz fix:
whole-title-goes-on-the-next-line

This allows to send slightly longer titles. This is still parsable as
we know that commit titles can't be empty.

Regarding another mail agent: again this only proves the point for me:
this is what tool developers are forced to be spending their resources
on, rather then working on adding more useful features...
I don't even know where to start re switching mail transport; how much
the switch will cost? what are other transport costs in the long term
maintenance? what are their problems?