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