This is the mail archive of the
mailing list for the glibc project.
Re: glibc git commit hooks update.
- From: Carlos O'Donell <codonell at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>, Mark Wielaard <mjw at redhat dot com>, Nick Clifton <nickc at redhat dot com>, Jeff Law <law at redhat dot com>, "Frank Ch. Eigler" <fche at redhat dot com>, Pedro Alves <palves at redhat dot com>, Florian Weimer <fweimer at redhat dot com>
- Date: Wed, 17 Apr 2019 20:20:39 -0400
- Subject: Re: glibc git commit hooks update.
- References: <email@example.com> <alpine.DEB.firstname.lastname@example.org>
On 4/17/19 6:21 PM, Joseph Myers wrote:
On Mon, 15 Apr 2019, Carlos O'Donell wrote:
* Sending an email and updating bugzilla are the same process,
and so you either get both or you get none. You cannot have
commit emails without bugzilla updates. Therefore we have opted
to have only commit emails and bugzilla updates for release and
master. This can be fixed but it needs extending in the existing
scripts to make the two operations distinct. For example if anyone
wants user branches to generate email commit messages then we'll
need to work on this.
I think user branches should generate emails (as I see it the point of
having such branches in this repository at all is visibility of the work
going on there, and that should include generating emails).
If we want user branches to generate emails *and* not update bugzilla
then we can do that. If you are requesting this then we'll have to work
with upstream AdaCore and the other projects to add this feature.
I'm not clear on whether the hooks were configured with any limit on the
size of diffs mailed, but if there is such a limit it should be at least
The default is 100KiB.
I have just pushed an update to allow up to 5MiB.
One problem with the old hooks was that they did not generate a
Content-Type header, which was unhelpful when the mails also weren't pure
ASCII. I see the new ones are generating 'Content-Type: text/plain;
charset="us-ascii"'. Will they also be smart about specifying an
appropriate character set (so UTF-8 if the commit message / author name /
diff contents are valid UTF-8 but not ASCII, for example)?
All of this is handled by python's email package and some handling
on the hooks part. If everything is ASCII then we don't do any special
encoding and just send ASCII. Otherwise we choose UTF-8 first and if
that fails a decode test then we fallback to ISO-8859-1.