Re: How can we decrease the cognitive overhead for contributors?

[Giovanni Biscuolo <g@xelera.eu>]

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

Hi,

interesting thread: thank you very much to all for the comments and
tips!

For email based patch workflow one and two things are indispensable: a
mailbox and a MUA capable of piping a message to a command (git am);
this is the one and only obstacle for contrubutors who are accustomed to
less than functional MUAs.

https://git-send-email.io/ is a good primer for the braves.

On the "cognitive overhead" for users like me who are able to (very)
seldom send some patch to projects, I find it much more straightforward
to just send a "git format-patch" generated file via email than to open
a web browser, log-in (or worst: register), fork... naah! 

On the general topic of "email vs. web (fork and PR) patch management" I
found this articles useful and interesting:

- «How I Learned to Love the Email Patch Developer Workflow» by Emily Shaffer
https://nasamuffin.github.io/git/open-source/email/code-review/2019/05/22/how-i-learned-to-love-email-patches.html

--8<---------------cut here---------------start------------->8---

With some tooling and good practices, I found a workflow that I love - and found myself arguing in defense of emailed patches!

[...]

* Responding to Comments

Note: As with Gerrit and other iterative code review tools based around a Git workflow, making your changes involves using interactive rebase. I won’t cover that here, as it’s not significantly different from other processes, and it’s complex enough to take its own tutorial.

--8<---------------cut here---------------end--------------->8---

- «Code review at the speed of email» by "Drew DeVault"
https://drewdevault.com/2022/07/25/Code-review-with-aerc.html

--8<---------------cut here---------------start------------->8---

With hundreds of hours of review experience on GitHub, GitLab, and SourceHut, I can say with confidence the email workflow allows me to work much faster than any of the others. I can review small patches in seconds, work quickly with multiple git repositories, easily test changes and make tweaks as necessary, rebase often, and quickly chop up and provide feedback for larger patches. Working my way through a 50-email patch queue usually takes me about 20 minutes, compared to an hour or more for the same number of merge requests.

This workflow also works entirely offline.

--8<---------------cut here---------------end--------------->8---

- «The advantages of an email-driven git workflow» by Drew DeVault
https://drewdevault.com/2018/07/02/Email-driven-git.html

--8<---------------cut here---------------start------------->8---

Email isn’t as sexy as GitHub (and its imitators), but it has several advantages over the latter. Email is standardized, federated, well-understood, and venerable. A very large body of email-related software exists and is equally reliable and well-understood. You can interact with email using only open source software and customize your workflow at every level of the stack - filtering, organizing, forwarding, replying, and so on; in any manner you choose.

[...] Given that most popular email clients these days are awful and can’t handle basic tasks like “sending email” properly, I strongly recommend this tool (git-send-email) over attempting to send format-patch’s output yourself.

[...] You can also set the default recipient for a given repository by using a local git config: git config sendemail.to admin@example.org. This lets you skip a step if you send your patches to a consistent destination for that project, like a mailing list. I also recommend git config --global sendemail.annotate yes, which will always open the emails in your editor to allow you to make changes (you can get this with --annotate if you don’t want it every time).

[...] The difficult part can be getting the email to git am in the first place. If you simply use the GMail web UI, this can be difficult.

[...] The main disadvantage of email driven development is that some people are more comfortable working with email in clients which are not well-suited to this kind of work. Popular email clients have caused terrible ideas like HTML email to proliferate, not only enabling spam, privacy leaks, and security vulnerabilities, but also making it more difficult for people to write emails that can be understood by git or tolerated by advanced email users.

I don’t think that the solution to these problems is to leave these powerful tools hanging in the wind and move to less powerful models like GitHub’s pull requests.

--8<---------------cut here---------------end--------------->8---

宋文武 <iyzsong@envs.net> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

>> For more information, try: 'guix shell info-reader u-boot -- info
>> "(u-boot) Patman patch manager"'
>
> Oh, patman look interesting for long series, will learn it later..

[...]

>> Using an Emacs-based workflow:
>>
>> 1. C-u M-x debbugs-gnu RET guix-patches RET [then answer prompts]
>> 2. M-x cd RET ~/src/guix or wherever is your guix checkout
>> 3. Select series you want to apply
>> 4. Sort by subject
>
> Also can first read on issues (mumi), find a issue ID,
> then M-x gnus-read-ephemeral-emacs-bug-group ID.

[...]

> Don't know the 'C-u 10 |' one, cool, thank you!

I feel like a section in the Cookbook about email based workflows would
be useful to many, even one with just excertps from this thread.

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]