Re: Mummi wishlist: API using Message-ID

[Julien Lepiller <julien@lepiller.eu>]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

As long as the script shows it's trying and explains why it takes time, it should be fine. It could offer a --continue option too :)

On June 6, 2022 2:03:16 PM GMT+02:00, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>Arun Isaac <arunisaac@systemreboot.net> writes:
>
>>> Once delpoyed to issues.guix.gnu.org you can visit
>>>
>>> https://issues.guix.gnu.org/msgid/HAv_FWZRa_dCADY6U07oX-E2vTrtcxk8ltkpfvTpYCsIh4O5PuItHGIh6w-g5GGmoqVEfkjDUOplpUErdGEPAiFYdrjjDhwd9RJ4OyjjGgY=@hector.link
>>
>> This is great news! Using this, we should be able to implement a `mumi
>> send-email' command to easily send N patches to a new issue. Here is
>> how `mumi send-email' might be implemented:
>>
>> 1. Generate patches with `git format-patch --thread' so that there is a
>>    Message-ID header.
>>
>> 2. Send the first patch to guix-patches@gnu.org.
>>
>> 3. Poll https://issues.guix.gnu.org/<message-id> to see if the first
>>    patch has reached Debbugs/Mumi. Find the issue number of the new
>>    issue that was created.
>>
>> 4. Send the remaining patches to the new issue.
>
>This sounds like it could take quite some time, and the work it performs
>is not transactional, so an impatient person cancelling it before
>completion could end up with a bunch of “initial” emails without ever
>sending the rest of the patches.
>
>I think that maybe we should wean mumi off of debbugs and operate on
>received email directly (using debbugs as a storage backend for the time
>being).
>
>-- 
>Ricardo
>

[-- Attachment #2: Type: text/html, Size: 2326 bytes --]