# Reflecting on Drew DeVault's email based workflow (2024-05-04)

**URL:** <https://pluralist.net/t/reflecting-on-drew-devaults-email-based-workflow-2024-05-04/151>\
**Category:** breadcrumbs\
**Created:** [May 4, 2024, 7:00am UTC](https://pluralist.net/t/reflecting-on-drew-devaults-email-based-workflow-2024-05-04/151 "2024-05-04T07:00:00Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![delyan](https://pluralist.net/user_avatar/pluralist.net/delyan/32/245_2.png) [@delyan](https://pluralist.net/u/delyan)\
**Post date:** [May 4, 2024, 7:00am UTC](https://pluralist.net/t/reflecting-on-drew-devaults-email-based-workflow-2024-05-04/151/1 "2024-05-04T07:00:00Z")

</div>

Earlier this year Drew DeVault appeared on [the Changelog podcast](https://changelog.fm/569) and, among other things, described his **email-based workflow**. Drew has developed a system where software development collaboration is handled through email rather than using web-based tools like GitHub or pull request platforms. This workflow of course is something that has been in use by the Kernel developer community for over 3 decades (Linus Torvalds announced the project to `comp.os.minix` on August 25, 1991). We are also reminded us of Sarah Novotny’s critique of the aforementioned workflow: [Relying on plain-text email is a ‘barrier to entry’](https://www.theregister.com/2020/08/25/linux_kernel_email/).

Here are the benefits Drew DeVault outlines:

- **Direct Contribution via Email** : Developers contribute code patches directly via email using commands such as `git send-email`. This is perceived faster than navigating multiple web pages or web forms.

- **Efficiency** : Drew argues that reviewing and managing code submissions via email allows for greater productivity. Patches and contributions are managed directly from the inbox, and even a high volume of emails can be handled quickly.

- **Unified Inbox** : By centralizing contributions and reviews in the inbox, the workflow provides a single place to monitor, review, and act on patches. This minimizes the need to switch between different tools or web interfaces.

- **Flexibility** : The workflow can be adapted to a wide range of projects, including open-source work, allowing the user to stay productive and maintain a clean inbox.

* * *

In a similar fashion [Greg Kroah-Hartman describes in detail](http://www.kroah.com/log/blog/2019/08/14/patch-workflow-with-mutt-2019/) how he uses mutt to manage the incoming Kernel patches. The examples and asciinema are a true treasure for the curious who want to improve their workflow!

Linus Torvalds himself has strong opinions on email, as the only scalable mechanism to manage the inbound Kernel patches:

- [25 Years Later: Interview with Linus Torvalds | Linux Journal](https://www.linuxjournal.com/content/25-years-later-interview-linus-torvalds)
- [Linus Torvalds: GitHub creates absolutely useless rubbish merge - SoByte](https://www.sobyte.net/post/2021-09/linus-torvalds-github/)
- [Re: [GIT PULL] ntfs3: new NTFS driver for 5.15 - Linus Torvalds](https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@mail.gmail.com/)
  - `you should never ever use the github interfaces to merge anything`
  - `github is a perfectly fine hosting site, and it does a number of other things well too, but merges is not one of those things`

- [10 Years of Git: An Interview with Git Creator Linus Torvalds - Linux Foundation](https://www.linuxfoundation.org/blog/blog/10-years-of-git-an-interview-with-git-creator-linus-torvalds)
- [An Interview With Linus Torvalds: Linux and Git - Part 1 | Tag1 Consulting](https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git)
- [An Interview With Linus Torvalds: Open Source And Beyond - Part 2 | Tag1 Consulting](https://www.tag1consulting.com/blog/interview-linus-torvalds-open-source-and-beyond-part-2)