Email subject line formatting

Robin Westberg robin.westberg at oracle.com
Mon May 4 13:12:32 UTC 2020


Hi all,

Before I start making changes, I’ll try to summarize what I think the current consensus looks like. But first a few inline comments:

> On 22 Apr 2020, at 19:23, mark.reinhold at oracle.com wrote:
> 
> 2020/4/17 2:58:18 -0700, magnus.ihse.bursie at oracle.com:
>> On 2020-04-17 10:46, Erik Helin wrote:
>>> ...
>>> 
>>> 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 https://www.gmail.com.
>> 
>> 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.
> 
> Let’s not do the wrong thing just to appease a broken MUA, no matter how
> popular it might be.

Right, I have performed various tests here, and the conclusion is that any change of the subject, except for inserting “Re: “ at the beginning (as well as a few localized versions, such as the Swedish variant Sv: for example) will make that MUA split a thread. So I also agree it’s not really worth taking into account.

>>> ...
>>> 
>>> 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).
> 
> So, theoretically, if the bots didn’t poll but were perfectly in sync
> with GitHub then these “FYI” messages wouldn’t be needed?

That’s not strictly true actually, the main source of delay here is that the bots are configured to wait a few minutes after the last update to a pull request body or comment before bridging it to a mailing list. This is to capture any quick last-minute edits, something which we have seen is reasonably common.

…

>>                                                    This would perhaps 
>> mean that the "git:" update mail would not be needed for those projects, 
>> since it would just duplicate this information.
> 
> I think there’s still value in the “git:” style messages, particularly
> for people who want to follow the stream of updates to a repo without
> having to scan every RFR thread for a terminal “Integrated” message.

Yes, I also think we should keep these separate. As it stands now, the “git:” messages are serviced through a different bot, to ensure that these work fine even for projects that mostly do not use pull requests (like Loom).

So in summary, these are the changes that I think we agree on:

- Normally, pull request emails are prefixed with “RFR:”
- Comments made in the pull request are prefixed “Re: RFR:"
- If the pull request is already integrated when the mail is generated, the prefix of the initial mail is “Integrated:” (changed from “Re: [Integrated] RFR:”)
- When integration happens, a reply to the original RFR mail is sent with the prefix “Integrated:"
- Further comments on an already integrated pull request are prefixed “Re: Integrated:”

There are a few more subject rewriting actions that happen as well:

If a pull request is closed without being integrated (a.k.a withdrawn), the prefix currently is "Re: [Closed] RFR:” - perhaps change this to “Closed:”?

An incremental update to a pull request creates a direct reply to the initial RFR mail, with the prefix “Re: [Rev 02] RFR:”. Further comments to the new changes are then threaded as replies to this mail. This makes it easy to see which revision a comment refers to. An option here that may look more similar to the new subjects would be “RFR: v2:” or similar. Thoughts?

Also, the changes will only affect the subjects of the generated emails - the threading headers will remain the same. Or are there any additional concerns or thoughts about how to arrange them to improve readability in thread-capable MUAs (such as the web archive)? I guess that could also be improved later.

Best regards,
Robin

> 
> - Mark



More information about the skara-dev mailing list