[RFC] On sending forge pull request discussions to the mailing list

[Christophe Lyon]

Hi Claudio,

Thanks for this comprehensive description!

On 4/2/26 08:50, Claudio Bantaloukas wrote:
> Hi folks,
> I've thought about Joseph's proposal to send all discussion happening on 
> forge to the mailing list*, specifically which bot workflows would need 
> to be implemented and what should happen at what time and here's a 
> slightly specific description that I plan to implement soon. I'm posting 
> this to get feedback as.
> 
> - A "PR rollup" means:
>    - if the user has force pushed a new version of the patch series, a 
> PR version is created
>    - if the current PR version has not been posted to the mailing list 
> yet, an up to date email patch series is sent
>    - messages related to the PR are sent as replies to the cover letter 
> of the latest patch series
>      - this includes all comments and reviews
>      - this includes requests to review
>      - excluding those that were already sent to the mailing list as 
> emails (the list is tracked on a database table)
>      - one message per comment or review
> 
> - Messages that must not be sent to the mailing list:
>    - all messages by the batrachomyomachia bot
>    - messages by the linaro bot (that do not include a <!-- bmm:send --> 
> tag in the comment, which is a convention we can ask the linaro bot to 
> adopt for comments that are meant to be sent to the mailing list)
>    - comments that include a <!-- bmm:nosend --> tag, which is a 
> convention to allow users to explicitly exclude certain comments from 
> being sent to the mailing list
>    - comments that contain the /submit or /preview command, since they 
> are meant to trigger an email rather than be included in the email 
> themselves
> 
> I think it will be enough to implement the following workflows in 
> batrachomyomachia:
> - when a PR is opened
>    - no email is sent
>    - user gets a welcome comment with guidance on how to use the bot and 
> the available commands (a shorter version than what we currently have!)
> 
> - when someone requests a review on a PR by setting the Reviewers list
>    - "PR rollup" occurs
> - when someone requests a review on a PR by writing a /submit comment
>    - "PR rollup" occurs
> - when someone posts a review on a PR (hits the Finish review button and 
> completes a review, with any review state)
>    - "PR rollup" occurs
> 
> - When someone writes a comment that is not filtered by the rules above
>    - if a patch email has already been sent for the PR, an email is sent 
> to the mailing list with the content of the comment, with In-Reply-To 
> set to the message id of the last cover letter, so that it is grouped in 
> the same thread.
>    Note that this is not PR rollup (random comments don't create a new 
> PR version and patch posting)
>    - if no patch email has been sent for the PR, no email is sent to 
> avoid sending messages that are not linked to a patch series. These 
> comments will be included in the email when a patch series is eventually 
> sent.
> 
> - when a PR is closed without being merged and no patch email has been 
> sent and no messages would be sent
>    - no email is sent as no interaction happened
> - when a PR is closed without being merged and at least one patch email 
> has been sent or at least one message would be sent
>    - a single email is sent to the mailing list notifying about the 
> closure, with In-Reply-To set to the message id of the last cover letter
>    - the email includes all comments and reviews in sequence
> 
> I think this strikes a balance between wanting to keep the mailing list 
> up to date with what's happening and overwhelming it with too many emails.

I agree this seems reasonable, all of the above makes sense.

> 
> One thing to add: the linaro bot currently updates existing comments so 
> it will be good to figure out which messages are a "final state" and 
> either make the bot recognize them or mark them with <!-- bmm:send -->.

Hmmm thanks to your help & suggestions a few months ago I managed to 
reduce the amount of comments generated by the Linaro bot using these 
HTML markers/comments: now it updates comments in place when the status 
changes (pending/running/completed).
How to detect a comment is the final one I'm not sure (if there's a 
crash during the "running" phase, there will probably never be a 
"completed" update).

Thanks!

Christophe


> 
> * https://forge.sourceware.org/forge/batrachomyomachia/issues/15
> 
> 
> Cheers
> Claudio