5 ms·

I like the user experience of forges far more than email clients. (1) It's hard to track the development of a patch in mailing lists unless you actively follow

I like the user experience of forges far more than email clients. (1) It's hard to track the development of a patch in mailing lists unless you actively follow it. Sometimes there will be a v7 patch but it gets buried in the sheer volume of other emails in the list. Sometimes discussions continue in the v6 thread while others occur in v7 so you have to track _both_ threads. And god forbid people changing subject lines thus breaking the thread. Meanwhile, discussions in forge workflow tend to be concentrated in the same merge request or issue. (2) Discovering patches is also a fairly difficult thing to do in mailing lists. The forges include tools like issue trackers and in each issue there is a list of all mentioned merge requests, and the status of those MRs (whether open, closed or merged) are immediately obvious. (3) I also like labels for similar reasons as (2) - don't get me wrong, I know email subjects often start with "some sort of tag:", but labels are sometimes used to mean "hey, this $MODULE1 code isn't directly related to $MODULE2, but might have some interactions with it so you should take a look". Cc-ing is a manual process which is annoying and like many manual processes is subject to human errors. (4) Emails rely heavily on conventions, e.g. should people top-post or bottom-post or inline-reply? That introduces a barrier of entry. As a sidenote, personally I hate that I occasionally have to scroll through long, long, emails that include reply chains from eons ago, but there's nothing email can really do to prevent it from happening. It's conventions all the way down.

bmacho 3y ago
> (1) It's hard to track the development of a patch in mailing lists unless you actively follow it. I would add that if you automatize it somehow, then you don't "just use e-mail", but you have a different protocol for it (over email in this case).
- myaccountonhn 3y ago
  I think the beauty of email is that it's already an open, federated standard. Is it easier to build this new activitypub layer on top of all forges, or is it easier to build a decent tool on top of email?
  - couchand 3y ago
    The answer to that question depends on where "the mindshare" is, and unfortunately we're living in a future where many seem to believe the former is easy and the latter impossible.
  - xyzzy_plugh 3y ago
    It would be nice if it were the latter but given the stranglehold the major email providers have over email I think it's a lost cause. Just look at the hoops you have to go through to send a patch over gmail.
globular-toast 3y ago
A lot of this could be solved with better tooling on your side, starting with a better mail reader. Mail readers have supported threading since before many of us were born. You don't have to follow an entire mailing list to follow a thread. I know we have to use normie mail readers for general communication but why are people so averse to using a proper mail set up when it makes sense, like for software development? We already use a ton of other tools specific to software development. A personal todo list system that integrates with your email is also essential. I don't understand how people don't do it. It's all very well forges having status of MRs etc. but surely your job isn't only merging MRs on GitLab? So you'll have other todo lists distributed over various places like other forges, Jira type things and, of course, your email. Why not consolidate all your todos into one place? If you're interested in a patch, add it to your todo list and check the status of it periodically. Conventions are good. It's part of being human. Learn how to use language to communicate with your fellow humans. It keeps the creative juices flowing.
- Hendrikto 3y ago
  > a lot of this could be solved with better tooling Yeah, better tooling like GitLab.
- argulane 3y ago
  Better tooling in Linux kernel case is moving everything to https://lore.kernel.org/ https://lore.kernel.org/ and https://b4.docs.kernel.org/en/latest/ https://b4.docs.kernel.org/en/latest/ witch mostly side steps the E-Mail part of the flow. The amount of people who have the free time to massage `.muttrc` for patch based flow is pretty small. And https://sr.ht/ https://sr.ht/ does not work for the volume that Linux kernel sees.
- orangeboats 3y ago
  >tooling I don't see why we should still use email when half of that requires "non-email" tooling then. I like using emails for person-to-person communication, not this. And what better tooling could it be if not a tool explicitly designed for software development, like GitHub/GitLab/Gitea? >Conventions are good. It's part of being human. It definitely won't keep the creative juices flowing when 99% of said conventions can be automated out. Rather, having to do everything manually impedes my ability to work on actual creative things. This paragraph is also semi-contradictory to your earlier paragraphs on tooling. I am replying to you on HN without manually typing "From:" "To:" because the website has automated that process for us. Furthermore, you are wholly sidetracking the core issue here which is "How can we enforce conventions?" The more laborious following a convention is, the harder it is to enforce the convention.

bmacho 3y ago

> (1) It's hard to track the development of a patch in mailing lists unless you actively follow it. I would add that if you automatize it somehow, then you don't "just use e-mail", but you have a different protocol for it (over email in this case).

myaccountonhn 3y ago
I think the beauty of email is that it's already an open, federated standard. Is it easier to build this new activitypub layer on top of all forges, or is it easier to build a decent tool on top of email?
- couchand 3y ago
  The answer to that question depends on where "the mindshare" is, and unfortunately we're living in a future where many seem to believe the former is easy and the latter impossible.
- xyzzy_plugh 3y ago
  It would be nice if it were the latter but given the stranglehold the major email providers have over email I think it's a lost cause. Just look at the hoops you have to go through to send a patch over gmail.

globular-toast 3y ago

A lot of this could be solved with better tooling on your side, starting with a better mail reader. Mail readers have supported threading since before many of us were born. You don't have to follow an entire mailing list to follow a thread. I know we have to use normie mail readers for general communication but why are people so averse to using a proper mail set up when it makes sense, like for software development? We already use a ton of other tools specific to software development. A personal todo list system that integrates with your email is also essential. I don't understand how people don't do it. It's all very well forges having status of MRs etc. but surely your job isn't only merging MRs on GitLab? So you'll have other todo lists distributed over various places like other forges, Jira type things and, of course, your email. Why not consolidate all your todos into one place? If you're interested in a patch, add it to your todo list and check the status of it periodically. Conventions are good. It's part of being human. Learn how to use language to communicate with your fellow humans. It keeps the creative juices flowing.

Hendrikto 3y ago
> a lot of this could be solved with better tooling Yeah, better tooling like GitLab.
argulane 3y ago
Better tooling in Linux kernel case is moving everything to https://lore.kernel.org/ https://lore.kernel.org/ and https://b4.docs.kernel.org/en/latest/ https://b4.docs.kernel.org/en/latest/ witch mostly side steps the E-Mail part of the flow. The amount of people who have the free time to massage `.muttrc` for patch based flow is pretty small. And https://sr.ht/ https://sr.ht/ does not work for the volume that Linux kernel sees.
orangeboats 3y ago
>tooling I don't see why we should still use email when half of that requires "non-email" tooling then. I like using emails for person-to-person communication, not this. And what better tooling could it be if not a tool explicitly designed for software development, like GitHub/GitLab/Gitea? >Conventions are good. It's part of being human. It definitely won't keep the creative juices flowing when 99% of said conventions can be automated out. Rather, having to do everything manually impedes my ability to work on actual creative things. This paragraph is also semi-contradictory to your earlier paragraphs on tooling. I am replying to you on HN without manually typing "From:" "To:" because the website has automated that process for us. Furthermore, you are wholly sidetracking the core issue here which is "How can we enforce conventions?" The more laborious following a convention is, the harder it is to enforce the convention.