|
|
Subscribe / Log in / New account

Emacs discusses web-based development workflows

Emacs discusses web-based development workflows

Posted Sep 7, 2021 16:43 UTC (Tue) by mathstuf (subscriber, #69389)
In reply to: Emacs discusses web-based development workflows by pizza
Parent article: Emacs discusses web-based development workflows

Email is fine and all. I understand; I use email as my central clearing house for things going on in the projects I use too. However, the problems with patches-over-email is felt, by me at least, on both the maintainer and contributor sides.

On the contributor side, there is no insight into the status of a patchset. I have 3 sent to Git recently. One got review and needs some work. I know that is in my court. However, that work led me to make 2 other patchsets as a base. One has received no response and it's not in the "What's cooking" summary either. The other went through some iterations before another (more regular) contributor took it over. These are in some state between contribution and accepted, but I don't know anymore because that state is sitting in someone's inbox somewhere. Has CI been run? Is it pending merging? As for the ignored patchset, how long before a friendly ping? Should the ping be a new thread with a resend of all the patches? The state machine is completely hidden from view and it discourages these kinds of "hey, wouldn't this be nice?" contributions with hidden bureaucracy.

On the maintainer side, collaboration between maintainers is visible. I don't have to fight different threading styles if there are two topics about different parts of the code (replying to both on each reply versus new subthreads for each topic). I can also see CI state (has it started? finished?), who is "in charge" of reviewing it, etc. Giving a patchset to a fellow maintainer for review is a state change (which turns into an email) rather than a crafted one handing it over. It's also visible to everyone.

Additionally, when joining a project, one is (usually) lacking the email archives to be able to contribute to in-progress threads at the right place versus able to just dive in on existing discussions seamlessly. For example, if I have the same problem as someone else and there's a thread I'd like to contribute to, I'd better have *already* been a subscriber to the list or I have to wait to receive a point to latch onto it. Hope it's a relevant subthread. Of course, one could trawl the archives for Message-Id headers and craft a reply yourself, but who wants to learn how to do that in their preferred email client?

I respect that email may be more comfortable for many, but its process opacity is just maddening to me. Do I wish things worked like debbugs with email able to control things *and* have a web interface into the current state? Sure. Has anyone built one yet? No. But *my* preferences are more towards facilitating the "paperwork" for the project as a whole rather than asking everyone to come up with their own inbox-based TODO list manager.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds