Re: Workflow with mu4e + magit for sending patchsets to guix?

[zimoun <zimon.toutoune@gmail.com>]

Hi Kyle,

Thank you for the detailed explanations and hints.


On Mon, 16 Nov 2020 at 21:36, Kyle Meyer <kyle@kyleam.com> wrote:

>>  4. !! send-email --to=guix-patches@gnu.org 0000-cover-letter.patch
>>  5. Wait and refresh my inbox
>>  6. !! send-email --to=12345@gnu.org 000?-*.patch
>
> Yeah, 4-6 are tricky and debbugs-specific.  For other projects, it could
> just be 'send-email *.patch' once sendemail.to is configured to point to
> the list's address.
>
> For 6, using '--no-thread --in-reply-to=...' will retain the same
> threading you'd see if you weren't using debbugs (i.e didn't have to do
> the two-step send).

[...]

> And, sadly I guess, my view is still similar to what I said there:
>
>   send-email has of course come up a number of times before (gh-1756 and
>   gh-1800 are the most relevant, I think), and tackling that requires a
>   vision that I don't really have.  Perhaps due to a lack of
>   imagination, I can't think of an implementation on Magit's side that
>   would improve the simple send-email command that I run.  In terms of
>   sending mail, the most involved thing that I need to do is get the
>   --to/--ccs and --in-reply-to from an existing thread, but in my view
>   that's outside of Magit's scope.
>
> I don't know.  Maybe I should try to think harder about it.
>
> A final note of hope: as a lurker on the notmuch list, I've noticed that
> Jonas has starting doing some patch-based contributions.  So, perhaps
> he'll get an itch and do his amazing Jonas thing.

To me, today the main annoyance is the selection of the patches at the
step #6.  For example, avoid to resend unrelated patches, as:

 - 000?-*.patch could resend the 0000-cover-letter.patch
 - *.patch could resend 0000-cover-letter.patch and 0001-Foo-bar.patch
    if I am currently sending v2-0001-Foo-bar.patch
 - any previous patchset remaining.  Recent example inside my
    guix-artwork checkout: 

--8<---------------cut here---------------start------------->8---
0000-cover-letter.patch
0001-website-Add-conference-announcement.patch
0001-website-Add-fetch-methods-to-JSON-sources-and-packag.patch
0001-website-Add-integrity-to-JSON-sources.patch
0001-website-Release-conference-schedule.patch
0001-website-Update-announce-online-Guix-days.patch
0001-website-Update-manifest.patch
tiny.patch
v2-0001-website-Add-conference-announcement.patch
v2-0001-website-Release-conference-schedule.patch
v3-0001-website-Add-conference-announcement.patch
v3-0001-website-Release-conference-schedule.patch
v4-0001-website-Add-conference-announcement.patch
v4-0001-website-Release-conference-schedule.patch
--8<---------------cut here---------------end--------------->8---


That’s why time to time I create an output directory and put the series
in.  But the 0000-cover-letter.patch (or vN-0000-cover-letter.patch) is
still annoying because it blocks the simple *.patch.  Nothing simpler
than * could be done, I see you regexp integrist. :-)


I am thinking loud.  One option (some setq) could be added to Magit
format-patch, and do under the hood:

 - create 0000-cover-letter.patch in the root directory
 - create folder v1 (default), otherwise v2 … vN and put the series
   in.

This would be configurable via Magit variables, say:

  magit-send-email-workflow t
  magit-format-patch-directory-prefix “v”
  
Then, the sequence,

  W C-m l C-m c
  W C-m v2 c
  W C-m l C-m v3 c

would produce the final tree:

  +
  +- .git
  +- 0000-cover-letter.patch
  +- v3-0000-cover-letter.patch
  +- v1
     +- 0001-Foo-Bar.patch
     …
     +- 0042-Yahoga.patch
  +- v2
     +- v2-0001-Foo-Bar.patch
     …
     +- v2-0012-Kikool.patch
  +- v3
     +- v3-0001-Foo-Bar.patch
     …
     +- v3-0021-Rock-and-roll.patch
 
This way, step #6 would become:

  !! send-email --to=12345@debbugs.gnu.org v1/*.patch

(With or without --in-reply-to, another story. :-))


All the best,
simon