Email subject line formatting

Wed May 6 07:54:13 UTC 2020

On 2020-05-04 15:12, Robin Westberg wrote:
> 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).
Sounds reasonable.
>
> 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:”
That sounds good to me.

>
> 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:”?
I think changing it to "Closed:" makes sense. Possibly even be more 
explicit, so "Withdrawn:" if it is withdrawn, etc (for whatever reasons 
it can be closed). "Closed" sounds like it *could* mean "I've integrated 
this now, so I just need to clean up afterwards" but "withdrawn" is very 
clearly saying "I won't be integrating this".
> 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?
My impression is that discussions about a patch in general is somewhat 
fluid, so that most of the time you don't really care what revision 
you're talking about. Sometimes you need to be explicit ("the new 
changes look good", "the solution in revision 1 was actually better than 
this"), but the important review discussions (e.g. "how does this fit in 
with the rest of the system") pertain to the patch as such, and not 
differences between revisions.

This means that the revision number is not terribly important. I think 
it's a good idea to have it in the subject (something which was not 
really possible prior to Skara), but it really needs to be unobtrusive. 
Your latter suggestion "RFR: v2:" is better than “Re: [Rev 02] RFR:”, 
but I'd even argue that the revision number should be added as a suffix 
instead, like this: "Re: RFR: Fix fnorbicator parsing [v2]".

> 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.
I don't really know what Skara does now, but I'd assume that each 
autogenerated mail from the next step in the process is made as a reply 
to the previous autogenerated, e.g.:
RFR (initial) --> RFR (rev2) --> Integrated.
And that comments to a PR is made as replies to the RFR mail of the 
revision being commented.

/Magnus
>
> Best regards,
> Robin
>
>> - Mark