Re: glibc git commit hooks update.

[Carlos O'Donell <codonell at redhat dot com>]

On 5/16/19 4:27 PM, Joseph Myers wrote:
> On Thu, 16 May 2019, Carlos O'Donell wrote:
> 
>> Therefore I think all projects should just default to UTF-8
>> encoded output for emails going to the list.
> 
> If the email text contains something that is *not* UTF-8 (if the patch 
> contains diffs to files that have some reason for being in another 
> encoding) then it's probably best not to label the email as being in 
> UTF-8.  Otherwise, labelling it as UTF-8 makes sense (including if in fact 
> it's in the ASCII subset of UTF-8).

Are you suggesting we drop Content-Type: and Content-Transfer-Encoding:
from the email entirely if we find non-UTF-8 content?

Otherwise we should always use UTF-8?

We can attempt a UTF-8 encoding, and if that fails, we must pick a fallback
encoding, unfortunately iso88591 will encode any stream of bytes, so we could
fall back to that?

In summary the rules would look like this:

- Attempt a UTF-8 encoding.
  - Fail? Send it out as ISO-8859-1.
- Pass? Send it out as UTF-8.

For the record, this is already the set of rules used for normalizing the
content in the header, subject, and other places, but is not currently
used overall for the message headers.

-- 
Cheers,
Carlos.