The future of stg mail

[jpgrayson]

See #185 for context.

For StGit 2.0, a big remaining open question is what to do about stg mail?

I'd like to either retire it entirely or replace it with a command that is more of a thin facade for git send-email. But I've never been a user of stg mail, so I remain fuzzy on the value proposition it offers versus plain git send-email. So I'm looking for StGit users that use email-based workflows to chime-in. I'm interested in both what people value about stg mail as well as why some of you bypass stg mail and use git send-email instead?

Some food for thought:

• What does stg mail p0..pN offer vis-a-vis git send-email $(stg id p0)..($stg id pN)?
  • My observation is that stg mail only provides a subset of the options and capabilities of git send-email/git format-patch, with few capabilities that differ.
• Do you use cover letter templates?
  • Is there something about stg mail's cover letter strategy that is different/better than git send-email?
  • git send-email --cover-from-description (or format.coverFromDescription in the config) seems to provide a similar capability. Is it good enough?
• What about patch templates?
  • Are they helpful?
  • Is there value deviating from the format of git format-patch?

Regarding the idea of "a thin facade for git send-email", I'm thinking about a stg send-email command that maps patchname/patchrange arguments to the revision-range arguments needed by git send-email, and then calls git send-email, transparently passing-through all other options. Would this be a good solution for emailing StGit patches?

[chucklever]

I've used "stg mail" since the beginning, and have never had to use "git send-email" so it's difficult for me to answer the questions you pose. However, there are some ideas I've had for "stg mail" for a while.

• Better integration with "patatt" for signing emails when DKIM is not available. Today I need "stg mail --git" to get patatt to work (see b4 for more detail about patatt). "stg mail --git" does not support the email aliases I have in in my ~/.gitconfig, and "--git" has been marked experimental forever anyway.

For the kernel e-mail workflow, I might send the same set of patches again after addressing review comments. That can happen again and again, and each of these is marked with a "vN". It would be great if the mail tool could handle post versioning naturally:

• Yes, I use a cover letter any time I'm sending a series of more than one patch. I'd like to edit and save the cover letter separately so that it can re-used when sending v2 .. vN of a series. Maybe "git send-email" can do this? The tool to manage the cover letter would need to deal with the template tokens as well (here's where the From: field goes; here's where the diff goes; etc).

• A more natural way for treating a branch as an e-mail series. This probably means I need to update my own workflow. But a branch with its own cover letter seems intuitive. Maybe a way to save the To/Cc list in a branch so I can re-use that list when sending v2 .. vN of the series. When sending a series, "stg mail" could manage the series version number automatically so I don't have to remember what version number to use for the next posting.

[jpgrayson]

I appreciate this detailed replay, @chucklever.

From what both you and @ctmarinas are saying, being able to associate a cover letter with a branch is important.

And having StGit tooling that helps with maintaining the series version would be a nice/novel addition as well.

Regarding DKIM and patatt, this is where I would really like StGit's solution to lean on git send-email. Although email is nominally a "simple" plain text protocol, there seems to be much arcane magic needed to send/receive/parse email correctly across all the exotic MTA's, MUA's, and MDA's out in the wild. In the Python implementation of StGit, we could use the smtp and email modules from the Python standard library (for better or worse), but the Rust standard library does not have any of those batteries included and I'm extremely hesitant to reach for yet more third-party dependencies.

Thus git send-email, which is already a necessary dependency of StGit, can do the heavy lifting. I also see value in reusing the rich configuration git already has for formatting and sending emails, i.e. the format.* and sendemail.* configuration items. Not reinventing those bits may help current users of git send-email and git format-patch use StGit more effectively.

But to your point, @chucklever, StGit needs to leverage git send-email in such a way that aliases and other current stg mail behaviors work correctly.

[chucklever]

Yep, as a stg user, I shouldn't really care about the underlying mechanism. I would like stg and git send-email to be more seamlessly integrated so I don't have to care.

[ctmarinas]

I use git send-email almost exclusively these days. One of the reasons is that I find it easier to do a git format-patch --cover and edit the cover letter, copy stuff from the previous version of the series, add changelog before sending it with git send-email.

What would be nice is if stgit can maintain a cover letter for a branch that I can edit (add changelog etc.) as I work on a series of patches. Maybe a 'stg branch --edit-cover' option (we have stg branch --description but this one only stores a text in .git/config). This way I won't need to do a git format-patch, vim 0000-cover-letter, git send-email.

Personally I'd offload all the mail delivery part (authentication, even aliases) to git and keep stg mail as a light wrapper that exports the patches and cover letter in a temporary directory before invoking git send-email.

[jpgrayson]

I've just made a v2.0.0-alpha.2 release that includes two new commands: stg email format and stg email send. These are thin wrappers on git format-patch and git send-email, respectively, but with the additional capability of selecting the patches to format/send from the StGit series.

I have not yet addressed associating a cover letter (or cover letter template) with the branch. I'd really like to hear from folks more tuned-into email-based workflows on exactly what cover letter capabilities should look like. For the time being, the capability is the same as what git provides, i.e. stg email format --cover will generate an editable cover letter template and/or stg email send --compose may be used to interactively edit the cover letter before sending.

Also not addressed is automating the series version (a.k.a. reroll count). The more I thought about this one, the less confident I felt about being able to automatically determine when the reroll count should increment. At format-time? At send-time? Resend the same version (perhaps to different recipients) is a thing, right? Anyway, I'm not confident on a path forward for this feature. Suggestions welcome.

N.B. I don't intend to hold-up the 2.0.0 release for additional email features. My hope is that what's there now is sufficient for the 2.0.0 release.

@ctmarinas @chucklever

[chucklever]

Simply saving the series version number and making it available to modify when editing the cover letter could be enough. Ie, something similar to how patch renaming is done with "stg edit".