Re: Not usable email content encoding

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi!

On Tue, Mar 17, 2020 at 03:51:58PM -0400, Frank Ch. Eigler via Gcc wrote:
> > > Are you trying to copy from the raw message representation?
> > 
> > Everyone trying to work with a patch (instead of just the email) always
> > is working with the raw message.  Just  patch < mbox  or  git-am mbox
> > for example.
> > 
> > https://gcc.gnu.org/contribute.html says
> >   It is strongly discouraged to post patches as MIME parts of type
> >   application/whatever, disposition attachment or encoded as base64 or
> >   quoted-printable.
> > 
> > (which many people still do not follow, making reviewing their patches
> > much harder than needed).
> 
> The key here is to realize that the raw message is not what you get
> back from the mailing list reflector,

Really?  It does not change any of this, afaik?  It never was like that
before, and if it now is, that makes this whole mailman experiment a
failure, imnsho.

> and also not the raw message
> that was sent by the sender.  In this day of mta intermediaries,
> proxies, reflectors, it may be time to revisit that suggestion.

Not really, no.  Any encoding is bad for most workflows.  MIME types
application/* or */x-* do not belong on mailing lists, by definition.
And attachments are (or should be!) just a last resort option to get
your patches through unmolested (and even then it does not always
work for everyone).

Of course most people use attachments with a bad MIME type or
disposition, making it harder to work with still.

> Attachments seem to survive unmolested better than mail email bodies,
> for example.  And MUAs can undo some of the unexpected transformations
> in the main body.

Yes, but not most.

People doing Free Software just need to learn how to use the various
tools involved correctly and effectively.  Email is one such tool.
There is no better one yet (all of the other code review options and
discussion platforms have much bigger downsides than upsides).  We
have been using this since forever, too, and we know how it works
(*including* this encoding/disposition/etc. problem, which has been
around for decades).


Segher