this post was submitted on 14 Sep 2023
108 points (95.0% liked)
Programming
17443 readers
331 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's archaic. The linux kernel has the amount of contributors using email because it literally is the only way to do so. The linux kernel can command its method of contribution because of its importance. If you start a new project and your only method of contribution is email, I bet you'll miss out on most contributors. Same as if you limit real-time communication to IRC only (but at least there's matrix for that).
Well there are many smaller projects than the kernel that still use the email workflow. To me it's simple, not archaic. You're right though, you definitely would miss out on contributors but that's just the reality of the dev world today.
It may be simple in the sense of it being "lowtech", but it certainly isn't easy, IMO. I'd have to read a guide on how to send a patch or apply one from somebody else. Commenting on a line of code and following a discussion about it isn't very legible. There's no way to mark a discussion as resolved, now way to have a quick overview of the status of all the comments left on a patch, is it possible to submit a patch with multiple commits and if so how does one see the final result? Is it possible to sign my commits?
The UI and UX are need a lot of work, IMO.
The guide is about 2 paragraphs and you'd also have to read a guide for how to create an account, fork, clone, push, send PR, etc. for the new normal workflow.
It's normal email bottom posting usually, pretty simple to follow. The srht UI does a decent job of this for you as well imho.
In email specifically, no. Of course you can mark it resolved if using custom software (ie, srht) that supports it. Not sure what you mean of quick overview, unless you mean via a webpage which again, srht provides. If straight email, you have to cycle through the emails. Which for me, just means typing "j" or "k" instead of page up/down like you would on GH, srht, whatever.
Yes, of course. No clue about seeing them all in one final patch. I suppose that's useful though I've never had an issue going through each patch individually. Maybe a feature suggestion for srht.
I don't see why not.
I've used email WF, then "github WF", and found srht very refreshing when it launched. I still stuck with BitBucket because I didn't want to take the time to move over but once they removed Mercurial support, we went all in with srht and no regrets. Our code review process via email is so much faster for us now and prior to this move, I was the only person on the team who'd worked with the email WF before.
Of course, I totally get it's a personal preference and that a lot of younger developers have no experience with the email WF and humans are naturally resistant to change. They probably wouldn't enjoy it either.