Email subject line formatting

Magnus Ihse Bursie magnus.ihse.bursie at
Fri Apr 17 09:58:18 UTC 2020

On 2020-04-17 10:46, Erik Helin wrote:
> On 4/14/20 8:32 PM, mark.reinhold at wrote:
>> 2020/4/14 1:18:20 -0700, magnus.ihse.bursie at
>>> On 2020-04-14 09:58, Magnus Ihse Bursie wrote:
>>> ...
>>>> Perhaps Jon is onto something that we should be more aggressive in how
>>>> the subject line is rewritten. When a change is actually integrated,
>>>> it is technically no longer a "RFR", so maybe rewrite to "Integrate:
>>>> Bug description ..." instead? As long as the In-Reply-To mail header
>>>> is correct, mail software should get the threading right regardless of
>>>> subject.
>> That would be preferable.
> I asked David to send the e-mail to see if there we could find 
> consensus around the e-mail prefixes, and it seems like we have done 
> just that :)
> Both me and Robin are personally fine with rewriting the subject line 
> more aggressively, we both use MUAs that thread based on the 
> "In-Reply-To" and "References" headers. I would just like to point out 
> that several MUAs do *not* thread solely on the "In-Reply-To" and 
> "References" headers, the most notable one being the Gmail browser 
> based MUA accessible at
Well, screw them. They can always use emacs instead. ;-)

But seriously, would gmail have problem handling a thread properly if 
you change the subject to be prefixed "Integrated: JDK-xxx ..." rather 
than "Re: [integrated] RFR: JDK-xxx ..."? It could be worth testing. If 
this special case is handled ok, then it's not really an issue if the 
general threading is borked by gmail.

> On 4/14/20 8:32 PM, mark.reinhold at wrote:
> >> On 2020-04-14 09:58, Magnus Ihse Bursie wrote:
>>> I also realise that on projects where a commit can be pushed without a
>>> review, the commit message is sent out as "FYI: Bug description...".
>>> This has also confused me, since it sounded like someone wanted to
>>> inform me about something, and not an auto-generated commit mail. Using
>>> "Integrated: Bug description..." would be beneficial here as well, I 
>>> think.
>> Is that always the case?  Or is there still the option (per-project,
>> I’d assume) to get the traditional “git: jdk/jdk: 87654321: ...” style
>> of message for commits that are not formally reviewed?
> It seems like there is some confusion here :) Skara features two ways 
> of notifying people following a mailing list that a patch has been 
> integrated:
> - the "traditional" notification e-mails that Mark refers to above.
>   These e-mails look exactly as their Mercurial counterparts.
> - a reply to the review thread stating the that the patch now has been
>   integrated. It is the subject line of these e-mails that we have been
>   discussing. This kind of notification e-mail is new with Skara, they
>   have no Mercurial counterpart.
> The second kind of notification is meant to help maintainers quickly 
> skim a mailing list. With a MUA that threads correctly it is very 
> quick to see whether the patch presented in an "RFR" thread has been 
> integrated or not.
> An OpenJDK project can choose the kind of e-mail notifications they 
> want to be sent to the project's mailing list. Some projects want both 
> of the above notifications, some projects feel that the reply to the 
> review thread is sufficient. Some projects use separate mailing lists 
> for the traditional notification emails and "RFR" emails, those have 
> opted to use both kind of notifications.
> Now, what are those e-mails prefixed with "FYI" that Magnus mentioned? 
> We use the "FYI" prefix instead of "RFR" when the bots send an email 
> for a pull request that has already been integrated. Since the bots 
> are polling they might encounter a pull request that was very quickly 
> integrated. This is most likely to happen for OpenJDK projects that do 
> not require reviews, where Committers can integrate their own pull 
> requests as soon as they are created (given that they pass jcheck). 
> Using the prefix "RFR" for this scenario felt wrong, since it is not a 
> request for review (the pull request has already been integrated). We 
> therefore opted for the "FYI" prefix to signal that we are conveying 
> information for something that has already happened. You can compare 
> this situation to one where you pushed a changeset and retroactively 
> send an e-mail with the webrev to a project's mailing list. This is an 
> orthogonal feature to any kind of notification e-mail being sent for 
> the integration.
I think their function was understood, and reasonable. I was merely 
reacting to the choice of the new tag "FYI" here, which to me implicated 
a general informational message ("FYI: is down right 
now"), rather than a source revision operation.

It also struck me that these mails are, in some way, the very same thing 
as the end result mail of a RFR thread. It's like a RFR but without the 
request for the reviews. :-) I thought it might make sense to treat both 
these kinds of mail the same, and use "Integrated:" as prefix for them 
both. As an added benefit, you would be able to search for "Integrated:" 
in a project mailbox, and see all integrations, both those that were 
pushed directly and those that were out for review. This would perhaps 
mean that the "git:" update mail would not be needed for those projects, 
since it would just duplicate this information.


> Thanks,
> Erik

More information about the skara-dev mailing list