7 ms·

Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclud

Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous. Sure, it's cool I can send a merge request to another server whatever, but... why are we like this

crotchfire 3y ago
Because people don't know about https://sr.ht https://sr.ht
- RamblingCTO 3y ago
  I'm intrigued, can you elaborate?
- joshxyz 3y ago
  does sourcehut support shat gitlab is trying to achieve here?
  - themk 3y ago
    Does sr.ht support cross instance patches? Yes. Even better, you don't even need an account on any sr.ht instance to send a patch, or receive one for that matter. It's just email. And it can do many of the things other forges do. Trigger builds, comment on patches, track issues, etc.
- SushiHippie 3y ago
  https://git-send-email.io/ https://git-send-email.io/
DANmode 3y ago
Enabling devs to be "social" in their way is a good trend.
anentropic 3y ago
> simply using email and git (ala Linux) to share, review and consume patches yeah, but when was the last time any of us did that...?
alufers 3y ago
For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. The typical interface for handling merge/pull requests adds so many useful things over just sending a patch - if the project has CI I can immediately see if it even successfully builds before even going into the details of the PR. Same for reviewing, each comment can be replied to separately or resolved, which serves as a nice TODO list for the original author. I know there are some things people don't like (I think Linus was pretty vocal about it), but it seems to be they could be easily fixed by modifying the available open-source forges. This proposal here for example fixes the concern about centralisation, so I guess it's a good step forward. Or maybe I'm just young and like shiny things and will eventually have a spiritual awakening and learn about the virtues of sending in patches via email.
- madeofpalk 3y ago
  The only way sending patches through email would actually work is if there was some interface on top of that process that managed that. By that point, it's probably easier to just use ActivityPub/HTTP as your protocol rather than SMTP/IMAP.
  - xyzzy_plugh 3y ago
    Absolutely, but it's depressing that we have to build a whole new system instead of dovetailing with a system that not only works but is already universally deployed.
  - taeric 3y ago
    I'm a little confused, there are interfaces on top of email based patch workflows? What do you mean?
- JoshTriplett 3y ago
  > For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. For me as a person who learned programming before the Internet was a thing, and has worked both on projects that do patches by email and on projects that use web-based pull requests, I also prefer the web-based pull requests in every possible way. The email based workflow is baroque, painful both to send and to receive, lacking in features, and error-prone.
orf 3y ago
> Contemplating this through the lens of simply using floppy disks and FedEx (ala Real Actual Serious Programming) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous. > Sure, it's cool I can send an email with a patch to another user instantly, but... why are we like this
orangeboats 3y ago
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?
    - 3y ago
konart 3y ago
Last thing I want in my workflow is fucking email. I understand that for some people digging through their email (and mailing lists archives) is fun but this is just a tiny minority.
- funcDropShadow 3y ago
  The difference is, I can customize my mail reader to my preferences. I can use macros to streamline my repetitive work with it. Neither is easily done with forges.
  - konart 3y ago
    Not every thing needs customization. Good defaults and good UI UX allow you to be done with your work quickly and even with some satisfaction from the process. Neither applies to email in my opinion.
    - funcDropShadow 3y ago
      But email does not have an UI, only mail reader application do have a UI. And many modern default mail reader applications have an awful UI, but that is not a sign of email being somehow bad.
      - orangeboats 3y ago
        That email clients is the way they are by default, should already say something, no? The majority of people use emails like electronic mails because that's what email is designed for! Source code sharing is a separate protocol bolted onto email, and the fact that you have to use a specific email client (which I should mention, is largely unheard of outside of a small circle) is indeed an admittance of email being bad. It's possible that you can fix a car with just a knife. But considering the difficulties and how unintuitive it is - is that not a sign of knife being somehow bad for the job?
        funcDropShadow 3y ago
LudwigNagasena 3y ago
But why do you need email if git is already built for decentralized communication? That's the core of the problem. Just add the ability to ask for pull requests, to comment, etc into git and nobody will build those insane protocol-on-top-of-a-protocol-to-communicate-with-a-side-protocol monstrosities.
- imiric 3y ago
  git-appraise[1] implements that concept. From Google, no less. I've never used it, or seen it used in the wild, but it always seemed intriguing, and like the obvious approach. The web UI traction is far greater for this to have any serious usage, but I wonder if Git had that ability from the start, if the web UI concept would've taken off as it did. [1]: https://github.com/google/git-appraise https://github.com/google/git-appraise
  - xyzzy_plugh 3y ago
    Similarly Gerrit stores everything, including permissions, in Git as well. I'm not sure there is an offline review flow yet, though, but it's certainly possible.
- phoe-krk 3y ago
  > Just add the ability to ask for pull requests, to comment, etc into git That's a major understatement. To "just" add this into mainline git, you'd essentially need to either fork git itself in order to add these features or figure a way to add this without making breaking changes, and then convince git maintainers that your PR is worth adding, and then convince enough people to actually use this new standard in place of what they already have (which will also need them to integrate this with their existing forge infrastructure to mitigate XKCD Standards).
Hendrikto 3y ago
You know that even Linus recently said that Linux has outgrown the email workflow and needs to find an alternative?
- aloisdg 3y ago
  Do you have a source for that? I would like to learn more about that
  - Hendrikto 3y ago
    Sure: > What is really needed, he said, is to find ways to get away from the email patch model, which is not really working anymore. He feels that way now, even though he is "an old-school email person". [0] [0]: https://lwn.net/Articles/952034/ https://lwn.net/Articles/952034/
  - argulane 3y ago
    E-mail based workflow for Linux is starting to break down as the amount of patches is too huge. * https://lwn.net/Articles/860607/ https://lwn.net/Articles/860607/ * https://lwn.net/Articles/952034/ https://lwn.net/Articles/952034/ * https://lwn.net/Articles/952146/ https://lwn.net/Articles/952146/ * https://lwn.net/Articles/950567/ https://lwn.net/Articles/950567/ * https://lwn.net/Articles/959069/ https://lwn.net/Articles/959069/ * https://lwn.net/Articles/815332/ https://lwn.net/Articles/815332/
    - avgcorrection 3y ago
      Very interesting, thanks for sharing. It’s nice to see a side of this which isn’t just about a clash of tech cultures (it seems).
rapnie 3y ago
Different tools, different audiences. Sibling comments show that many people prefer the rich UI's that Gitlab, Github, Gitea etc. offer, while others prefer more hardcore brutal minimalism. Each audience is served with their favorite tools. For instance Sourcehut is a great product if you like mail and sending patches. What I find a bit tiresome, and witness mostly 'the minimalists' doing so, is people coming in with "This is shite" religious notions on what is 'the right way'. There is choice. And that is wonderful.
mariusor 3y ago
> why are we like this It's not clear about what you're complaining here. What exactly is ridiculous? This just offers a different channel through which to circulate patches. Unlike email, which requires everyone follow some ad-hoc convention in the email message, with ActivityPub the protocol itself can support structured data about the patch.
ekianjo 3y ago
why are we like this? because decentralization removes power from big corps. thats justification enough.
badrequest 3y ago
"Why are people making new tools instead of using the antiquated ones I'm familiar with?"
avgcorrection 3y ago
I’ve used email a bit and there are some pros and cons. For email: It’s just there already, like you mention. Once you are setup you can do things like comment on a “line of code” very straightforwardly. It’s already distributed and all that. There are bespoke (project-specific probably) bridges from forges (maybe mostly GitHub) to mailing lists. For this new thing: You don’t have to worry about all the legacy of email. You don’t have to worry about 90% of the world using email “wrong” according to techies. You can probably track changes more easily than keeping track of where you sent patches. You don’t have to make bespoke forge-to-email bridges.
radarsat1 3y ago
I've wondered if there might be room for services that use email as their communication channel. Something like this would be perfect for it. The forges would send emails to communicate in issues, information is distributed via mailing lists, but forges parse and display the information in their own way. They become fancy single-purpose email clients basically. With such a system, people could also contribute by writing the same emails by hand, as long as the format remains accessible. And no special protocols necessary, all existing mailing list infrastructure can be used instead of designing new complicated ways of doing the same thing.

crotchfire 3y ago

Because people don't know about https://sr.ht https://sr.ht

RamblingCTO 3y ago
I'm intrigued, can you elaborate?
joshxyz 3y ago
does sourcehut support shat gitlab is trying to achieve here?
- themk 3y ago
  Does sr.ht support cross instance patches? Yes. Even better, you don't even need an account on any sr.ht instance to send a patch, or receive one for that matter. It's just email. And it can do many of the things other forges do. Trigger builds, comment on patches, track issues, etc.
SushiHippie 3y ago
https://git-send-email.io/ https://git-send-email.io/

DANmode 3y ago

Enabling devs to be "social" in their way is a good trend.

anentropic 3y ago

> simply using email and git (ala Linux) to share, review and consume patches yeah, but when was the last time any of us did that...?

alufers 3y ago

For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. The typical interface for handling merge/pull requests adds so many useful things over just sending a patch - if the project has CI I can immediately see if it even successfully builds before even going into the details of the PR. Same for reviewing, each comment can be replied to separately or resolved, which serves as a nice TODO list for the original author. I know there are some things people don't like (I think Linus was pretty vocal about it), but it seems to be they could be easily fixed by modifying the available open-source forges. This proposal here for example fixes the concern about centralisation, so I guess it's a good step forward. Or maybe I'm just young and like shiny things and will eventually have a spiritual awakening and learn about the virtues of sending in patches via email.

madeofpalk 3y ago
The only way sending patches through email would actually work is if there was some interface on top of that process that managed that. By that point, it's probably easier to just use ActivityPub/HTTP as your protocol rather than SMTP/IMAP.
- xyzzy_plugh 3y ago
  Absolutely, but it's depressing that we have to build a whole new system instead of dovetailing with a system that not only works but is already universally deployed.
- taeric 3y ago
  I'm a little confused, there are interfaces on top of email based patch workflows? What do you mean?
JoshTriplett 3y ago
> For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. For me as a person who learned programming before the Internet was a thing, and has worked both on projects that do patches by email and on projects that use web-based pull requests, I also prefer the web-based pull requests in every possible way. The email based workflow is baroque, painful both to send and to receive, lacking in features, and error-prone.

orf 3y ago

> Contemplating this through the lens of simply using floppy disks and FedEx (ala Real Actual Serious Programming) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous. > Sure, it's cool I can send an email with a patch to another user instantly, but... why are we like this

orangeboats 3y ago

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?
  - 3y ago

konart 3y ago

Last thing I want in my workflow is fucking email. I understand that for some people digging through their email (and mailing lists archives) is fun but this is just a tiny minority.

funcDropShadow 3y ago
The difference is, I can customize my mail reader to my preferences. I can use macros to streamline my repetitive work with it. Neither is easily done with forges.
- konart 3y ago
  Not every thing needs customization. Good defaults and good UI UX allow you to be done with your work quickly and even with some satisfaction from the process. Neither applies to email in my opinion.
  - funcDropShadow 3y ago
    But email does not have an UI, only mail reader application do have a UI. And many modern default mail reader applications have an awful UI, but that is not a sign of email being somehow bad.
    - orangeboats 3y ago
      That email clients is the way they are by default, should already say something, no? The majority of people use emails like electronic mails because that's what email is designed for! Source code sharing is a separate protocol bolted onto email, and the fact that you have to use a specific email client (which I should mention, is largely unheard of outside of a small circle) is indeed an admittance of email being bad. It's possible that you can fix a car with just a knife. But considering the difficulties and how unintuitive it is - is that not a sign of knife being somehow bad for the job?
      - funcDropShadow 3y ago

LudwigNagasena 3y ago

But why do you need email if git is already built for decentralized communication? That's the core of the problem. Just add the ability to ask for pull requests, to comment, etc into git and nobody will build those insane protocol-on-top-of-a-protocol-to-communicate-with-a-side-protocol monstrosities.

imiric 3y ago
git-appraise[1] implements that concept. From Google, no less. I've never used it, or seen it used in the wild, but it always seemed intriguing, and like the obvious approach. The web UI traction is far greater for this to have any serious usage, but I wonder if Git had that ability from the start, if the web UI concept would've taken off as it did. [1]: https://github.com/google/git-appraise https://github.com/google/git-appraise
- xyzzy_plugh 3y ago
  Similarly Gerrit stores everything, including permissions, in Git as well. I'm not sure there is an offline review flow yet, though, but it's certainly possible.
phoe-krk 3y ago
> Just add the ability to ask for pull requests, to comment, etc into git That's a major understatement. To "just" add this into mainline git, you'd essentially need to either fork git itself in order to add these features or figure a way to add this without making breaking changes, and then convince git maintainers that your PR is worth adding, and then convince enough people to actually use this new standard in place of what they already have (which will also need them to integrate this with their existing forge infrastructure to mitigate XKCD Standards).

Hendrikto 3y ago

You know that even Linus recently said that Linux has outgrown the email workflow and needs to find an alternative?

aloisdg 3y ago
Do you have a source for that? I would like to learn more about that
- Hendrikto 3y ago
  Sure: > What is really needed, he said, is to find ways to get away from the email patch model, which is not really working anymore. He feels that way now, even though he is "an old-school email person". [0] [0]: https://lwn.net/Articles/952034/ https://lwn.net/Articles/952034/
- argulane 3y ago
  E-mail based workflow for Linux is starting to break down as the amount of patches is too huge. * https://lwn.net/Articles/860607/ https://lwn.net/Articles/860607/ * https://lwn.net/Articles/952034/ https://lwn.net/Articles/952034/ * https://lwn.net/Articles/952146/ https://lwn.net/Articles/952146/ * https://lwn.net/Articles/950567/ https://lwn.net/Articles/950567/ * https://lwn.net/Articles/959069/ https://lwn.net/Articles/959069/ * https://lwn.net/Articles/815332/ https://lwn.net/Articles/815332/
  - avgcorrection 3y ago
    Very interesting, thanks for sharing. It’s nice to see a side of this which isn’t just about a clash of tech cultures (it seems).

rapnie 3y ago

Different tools, different audiences. Sibling comments show that many people prefer the rich UI's that Gitlab, Github, Gitea etc. offer, while others prefer more hardcore brutal minimalism. Each audience is served with their favorite tools. For instance Sourcehut is a great product if you like mail and sending patches. What I find a bit tiresome, and witness mostly 'the minimalists' doing so, is people coming in with "This is shite" religious notions on what is 'the right way'. There is choice. And that is wonderful.

mariusor 3y ago

> why are we like this It's not clear about what you're complaining here. What exactly is ridiculous? This just offers a different channel through which to circulate patches. Unlike email, which requires everyone follow some ad-hoc convention in the email message, with ActivityPub the protocol itself can support structured data about the patch.

ekianjo 3y ago

why are we like this? because decentralization removes power from big corps. thats justification enough.

badrequest 3y ago

"Why are people making new tools instead of using the antiquated ones I'm familiar with?"

avgcorrection 3y ago

I’ve used email a bit and there are some pros and cons. For email: It’s just there already, like you mention. Once you are setup you can do things like comment on a “line of code” very straightforwardly. It’s already distributed and all that. There are bespoke (project-specific probably) bridges from forges (maybe mostly GitHub) to mailing lists. For this new thing: You don’t have to worry about all the legacy of email. You don’t have to worry about 90% of the world using email “wrong” according to techies. You can probably track changes more easily than keeping track of where you sent patches. You don’t have to make bespoke forge-to-email bridges.

radarsat1 3y ago

I've wondered if there might be room for services that use email as their communication channel. Something like this would be perfect for it. The forges would send emails to communicate in issues, information is distributed via mailing lists, but forges parse and display the information in their own way. They become fancy single-purpose email clients basically. With such a system, people could also contribute by writing the same emails by hand, as long as the format remains accessible. And no special protocols necessary, all existing mailing list infrastructure can be used instead of designing new complicated ways of doing the same thing.