> So, the current SVN mails are like:
> Subject: r280117 - in /trunk/libstdc++-v3: ChangeLog tes...
> To: gcc-...@gcc.gnu.org
>
> Author: redi
> Date: Fri Jan 10 15:27:50 2020
> New Revision: 280117
>
> URL: https://gcc.gnu.org/viewcvs?rev=280117&root=gcc&view=rev
> Log:
> libstdc++: Fix testcase for C++98 compatibility
>
>         * testsuite/25_algorithms/equal/deque_iterators/1.cc: Don't use C++11
>         initialization syntax.
>
> Modified:
>     trunk/libstdc++-v3/ChangeLog
>     trunk/libstdc++-v3/testsuite/25_algorithms/equal/deque_iterators/1.cc
>
> and the body is what is added into the bugzilla.
> Now, looking at the git test mail, I see:
> Subject: [gcc-reposurgeon-8] Test git hooks interaction with Bugzilla.
> To: gcc-...@gcc.gnu.org
>
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b
>
> commit 3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b
> Author: Joseph Myers <jos...@codesourcery.com>
> Date:   Thu Jan 9 21:44:05 2020 +0000
>
>     Test git hooks interaction with Bugzilla.
>
>         PR c/93218
>         * Test git hooks interaction with Bugzilla.
>
> Diff:
> ...
>
> and into bugzilla goes:
> The master branch has been updated by Joseph Myers <js...@gcc.gnu.org>:
>
> followed by the mail body above Diff:.
> I'm not sure if we need the repository name (I bet it will be gcc when
> switched over) in the subjects because all mails in gcc-cvs mailing list
> will be for that repo (guess it depends on how many people actually actively
> use that mailing list, whether they procmail them into separate folders (I
> do), or not and what they prefer).
>
> Having the one-line description of the change in the subject is a positive
> change.
>
> The changes I was asking for is, for gcc master and releases/gcc-* branch
> commits to have the monotonically increasing short ids (printed by git descr
> <commithash> with the git aliases I've posted) both somewhere early
> in the subject before the one-line description, and somewhere in the body
> too.  For release branch commits, perhaps the
> [gcc(refs/releases/gcc-9)]
> or whatever exactly release branch commits would print would be unnecessary,
> r10-1234
> as 1234th's commit after the branchbase of trunk (i.e. first commit after
> branching 9 release branch) or r9-2345 would contain that information
> already.  Or if we want to say gcc in there too, let's do it, but not too
> much over that.
> The URL which is printed separately perhaps would be nicer to into the same
> block, so have
> commit 3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b
> URL:    
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b
> Author: Joseph Myers <jos...@codesourcery.com>
> Date:   Thu Jan 9 21:44:05 2020 +0000
> Id:     r10-1234
>
> before the rest, where we could teach bugzilla customization which now
> URL-izes rNNNNN for 1-6 decimal digits into https://gcc.gnu.org/rNNNNN
> to also URL-ize rNN-NNNN for 1-2 + 1-5 decimal digits into
> https://gcc.gnu.org/rNN-NNNN and let that redirect to the corresponding
> commit in gitweb.
>
> Maybe even add https://gcc.gnu.org/gNNNNNNN for 7-40 hexadecimal digits
> redirect to https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=NNNNNNN
> and then just put as URL those
> https://gcc.gnu.org/g3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b
> URLs instead to make it somewhat shorter, and again teach bugzilla to
> URLize g3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b with 7-40 hexadecimal
> digits.

I have had some time to think about this, and for me, the format
you are looking for and the conditions under which you want that
format to be activated are very specific to GCC. What I am thinking
I can do to help support you is just define a couple of hooks
that would call scripts that you could use to override the default
email subject and body formats. Then GCC can have the exact email
that they need.

FWIW:

  - Regarding the name of the repository being provided at the beginning
    of the subject: this is a useful piece of information to have
    as soon as one doesn't store these emails for this specific
    repository inside their own mailbox. I really think it is worth
    keeping.

  - I don't understand the value of having that "monotonic" number.

    I am wondering if it is something that you are trying to replicate
    from the SVN days, and whether it still have enough value that
    you would want to crowd the email subject with that piece of
    information?

    Perhaps the answer to my questions are somewhere in the middle,
    and it is sufficient to have it in the email body alone?

-- 
Joel

Reply via email to