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 <rek...@elephly.net> wrote: > >Arun Isaac <arunis...@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-patc...@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 >
