3 ms·

> I agree that e-mail is not perfect, but... how is GitHub better? Please look at my comment again. I prefer email to locked in forges. > Devs like new shiny

by goku12 3y ago

> I agree that e-mail is not perfect, but... how is GitHub better? Please look at my comment again. I prefer email to locked in forges. > Devs like new shiny toys, and e-mails are old technology There is one aspect where such forges have an advantage over email - a better user experience. Aerc and the likes all good - but Github and others provide a good user experience over a tool that everyone uses - the web browser. > we should have something better than e-mail in 2023 We really should have something better than email. I'm saying this as someone who operates a personal mail server and a bunch of desktop services for it. It's really hard to get the setup correct. In that context, it's worth looking at forgefed (https://forgefed.org/ https://forgefed.org/). It's a protocol for federating forges like Gitea and Gitlab. It's built on top of ActivityPub - which behaves a bit like email (it has inboxes and outboxes for every user). From the spec, it seems like pull requests happen by sending patches to the destination forge. > Nobody takes the time to try the e-mail workflow (even though it's really two git commands) Email workflow seems simple. But there are two things that make it complicated: 1. The patches don't specify the commits they apply to. It's simply assumed that they apply to the head of the main branch. The commits have to be carefully rebased on the main branch before sending the patches. It could otherwise lead to conflicts and a lot of wasted time. 2. Each commit/patch is send as a single email. Developers usually make frequent commits when they develop. Such patches can be confusing and hellish to review. A sane patchset requires the developers to edit the commit history, usually using interactive rebases. Each commit should contain a single feature and shouldn't break the build. I consider both the above to be good development practices and follow them even on my personal projects. However, this is an additional barrier to entry. In fact, this may be a bigger problem for many than setting up git for email.

palata 3y ago
> We really should have something better than email. Maybe, but e-mail is here, the whole world knows and uses it, and even if it is not perfect, I think it does the job pretty well (put aside the fact that managing a server is hard). > However, this is an additional barrier to entry. Agreed. I just feel like we keep pushing the barrier down, but at some point, professionals need to learn the basics. I don't feel like we need more software in our world. We need better software. And if people can't learn their tools, I don't know if we can seriously expect them to write good software...
- goku12 3y ago
  > And if people can't learn their tools, I don't know if we can seriously expect them to write good software... Last time I suggested [1] an approach to learning and taming the git CLI, somebody said that they want to design and write code, rather than learn too much CLI-fu. Big projects like Linux and Emacs can get away with requiring their contributors to learn the tools well enough. However, many developers may decide to avoid contributing rather than learn the tool, if the project is a small one. Again, I agree with what you say - that's what I practice too. [1] https://news.ycombinator.com/item?id=37014286 https://news.ycombinator.com/item?id=37014286
- viraptor 3y ago
  > but at some point, professionals need to learn the basics Think about a junior joining a company. Through the first weeks they get: to be useful you need to learn about dependency management, git, frameworks we use, data stores we use, processes for review, our ci approach, our release approach, ... Adding yet another process your work depends on, is fiddly to setup and doesn't have good docs online really isn't great. "We can add this on top, it's just basics" can really add up with enough systems.
  - palata 3y ago
    > "We can add this on top, it's just basics" can really add up with enough systems. That's the thing. In my view, you say "we should keep adding wrappers on top of wrappers and libraries on top of libraries, such that juniors can quickly get productive, but nobody actually understands what they are doing anymore and the smallest executable takes 50MB". I say "we should reduce the number of dependencies such that one can understand the system better, even if it means that juniors need to spend time learning the basics". Of course there is a balance to find (not everybody needs to master assembly), but the modern way, IMHO, goes too much towards productivity, and not enough towards mastering ones tools.

by goku12 3y ago

palata 3y ago

> We really should have something better than email. Maybe, but e-mail is here, the whole world knows and uses it, and even if it is not perfect, I think it does the job pretty well (put aside the fact that managing a server is hard). > However, this is an additional barrier to entry. Agreed. I just feel like we keep pushing the barrier down, but at some point, professionals need to learn the basics. I don't feel like we need more software in our world. We need better software. And if people can't learn their tools, I don't know if we can seriously expect them to write good software...

goku12 3y ago
> And if people can't learn their tools, I don't know if we can seriously expect them to write good software... Last time I suggested [1] an approach to learning and taming the git CLI, somebody said that they want to design and write code, rather than learn too much CLI-fu. Big projects like Linux and Emacs can get away with requiring their contributors to learn the tools well enough. However, many developers may decide to avoid contributing rather than learn the tool, if the project is a small one. Again, I agree with what you say - that's what I practice too. [1] https://news.ycombinator.com/item?id=37014286 https://news.ycombinator.com/item?id=37014286
viraptor 3y ago
> but at some point, professionals need to learn the basics Think about a junior joining a company. Through the first weeks they get: to be useful you need to learn about dependency management, git, frameworks we use, data stores we use, processes for review, our ci approach, our release approach, ... Adding yet another process your work depends on, is fiddly to setup and doesn't have good docs online really isn't great. "We can add this on top, it's just basics" can really add up with enough systems.
- palata 3y ago
  > "We can add this on top, it's just basics" can really add up with enough systems. That's the thing. In my view, you say "we should keep adding wrappers on top of wrappers and libraries on top of libraries, such that juniors can quickly get productive, but nobody actually understands what they are doing anymore and the smallest executable takes 50MB". I say "we should reduce the number of dependencies such that one can understand the system better, even if it means that juniors need to spend time learning the basics". Of course there is a balance to find (not everybody needs to master assembly), but the modern way, IMHO, goes too much towards productivity, and not enough towards mastering ones tools.