4 ms·

No, it's not unfamiliarity, I have had to use email to manage and submit patches before, and hated it. This just stinks of doing things the old way in cargo cul

No, it's not unfamiliarity, I have had to use email to manage and submit patches before, and hated it. This just stinks of doing things the old way in cargo cult like fashion. This whole approach, some development in email, some on the web, and some on a disused IRC channel is exactly why projects like Cairo suffer from lack of contributions. Do people really want to deal with text patches in 2020? I appreciate the back-to-basics approach and aesthetics, but srht just seems to be throwing out the baby with the bathwater.

ddevault 6y ago
>is exactly why projects like Cairo suffer from lack of contributions I don't really agree with this. Many projects enjoy a vibrant development community on mailing lists today. Cairo suffers from different issues - and ultimately in Cairo's case it doesn't really matter. Cairo has been "done" for years, it's not the end of the world if it doesn't see much activity. >Do people really want to deal with text patches in 2020? Yes. You'll find many of them in this very thread. SourceHut is a brand-new service, only around for 2 years in alpha, and in 2020 alone it transacted 37,000 emails. There's obviously demand here. One thing that can matter a lot if you're trying out the email workflow is making sure you're using a good client. I made one that I recommend as such: https://aerc-mail.org https://aerc-mail.org. Other good choices include mutt and alpine.
- Znafon 6y ago
  Do you have a recommendation for a good GUI mail client?
  - ddevault 6y ago
    Claws mail is pretty good IMO. There are some more options here: https://useplaintext.email https://useplaintext.email
    - Znafon 6y ago
      Thanks, last time I tested aerc I couldn't find a way to make it download all my mails locally. Is this possible?
      - Icyphox 6y ago
        Try mbsync or OfflineIMAP. Both great tools to sync a remote mailbox to local.
      - ddevault 6y ago
        No, but you can use it in combination with something like imapsync.
- hvis 6y ago
  Can you comment on individual lines of a changeset in an email and reply to such comments separately, and then see such conversations in the context of the diff? And then mark them as resolved when that happens? Can you read those discussions later in a "flat" presentation without scrolling through emails one-by-one? These are some of the killer features of the PR/MR Github/Gitlab workflows. To clarify, I'm talking about steps 4-7 here: https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request https://docs.github.com/en/free-pro-team@latest/github/colla... As well as the "Resolving conversations" section.
  - ddevault 6y ago
    >Can you comment on individual lines of a changeset in an email and reply to such comments separately, and then see such conversations in the context of the diff? And then mark them as resolved when that happens? Yes, except for the last bit. Unlike GitHub/GitLab you can also respond to several comments at once. >Can you read those discussions later in a "flat" presentation without scrolling through emails one-by-one? I don't know what this means.
    - comex 6y ago
      Judging from my GitHub experience, I think they mean seeing, under each chunk of code, the whole conversation thread pertaining to that chunk. In other words, where a standard mailing list format looks like: Person 1 > Chunk of code 1 Comment > Chunk of code 2 Comment Person 2 > Chunk of code 1 Comment > Chunk of code 2 Comment they want a view like: Chunk of code 1 Person 1 Comment Person 2 Comment Chunk of code 2 Person 1 Comment Person 2 Comment
      - ddevault 6y ago
        Yeah, we have a view like that.
        6y ago
- Qwertious 6y ago
  "and in 2020 alone it transacted 37,000 emails. There's obviously demand here." Um, what? Suppose you have 10 developers sending an average of 10 emails a day. That's 100 * 365, or 36 500 emails a year. That stat doesn't sound very useful. 10 developers isn't demand.
  - ddevault 6y ago
    Most projects on SourceHut don't receive anywhere near 10 patches per day. There are not any many large projects on sr.ht - established projects are slow to move off other platforms, and new projects haven't had a lot of time to gather steam. The top lists peak at like, 3 per day. What matters more is their volume: 1,447 of them were created in 2020.
- nyanpasu64 6y ago
  >Cairo has been "done" for years, it's not the end of the world if it doesn't see much activity. Cairo's fast antialiasing mode had a memory corruption bug that took 5 years after the bug report to be fixed. https://gitlab.freedesktop.org/cairo/cairo/-/issues/44 https://gitlab.freedesktop.org/cairo/cairo/-/issues/44
aaravchen 6y ago
For one, many corporate environments no longer directly tie email user identity and code user identity directly together, they frequently manage them thru a third service that both services connect to instead (e.g. OAuth, ActiveDirectory, etc). This also only works well if you have: 1) one commit per change, 2) every reviewer has a fully up to date copy of any/all repos being reviewed, 3) a single change only affects a single repo. The one-commit-per-change (squashed changes) is not always the preference, but it's effectively mandatory since the presentation format for patches only lends itself well to an isolated patch-diff and not a VCS history of changes (ironic since it's intended for the latter). As a great example of this, it's very difficult to compare the differences between the resulting code between two patches submitted to the same thread when I want to confirm a series of corrections to the original submissions were made properly and without side-effect. Every reviewer having a fully up-to-date copy of the repo the changes are going into works amazingly well for a fully distributed VCS, defining the gatekeeping maintainer's copy as the ultimate source of truth for the "latest". When multiple maintainers for the repo exist, as in most corporate environments and the monorepo organization, this breaks down. The ultimate source of truth for "latest" is now a remotely hosted repository that no one individual gatekeeps. Therefore all maintainers need to constantly duplicate the remote copy and keep it up to date. Either the maintainer is an active developer that's also creating changes constantly and will therefore need to keep two different copies so they can be building and testing their own development changes while keeping a pristine copy purely for review purposes, or they don't usually do a lot of active development themselves and keeping a local copy at all is purely for the purposes of review. In terms of pushing proliferation of copies of the distributed VCS it works, but when more (but not completely) centralized as most corporate environments/users need it's an extra hurdle that impedes the process rather than helping. For a single change to affect only a single repo requires at the extreme a monorepo layout, or an extremely well modularized design. As noted before, monorepo is very much against the design (few people should need a fully history copy of the entire repo locally with a monorepo, and many maintainers control the same repo) and defining sufficiently modularized breakdown is nigh impossible with larger projects. The Linux project is a great example of this problem, but has a semi-solution that involves having an even larger developer base involved at different levels of a heirarchy, and split repos for "modules" (independently maintained subcomponents or specialty areas) that have to manually cross-related. This is demonstrably problematic even now when a sub-area uses a separate repo and submits wholesale changes to the downstream project, losing almost all of the history and cross-linked-tracking information in so doing. Recognized as a common problem, the community has either gone the monorepo route where all changes go into the single larger repo at the cost of much greater coordination requirements, or the submodule-like route where each sub-part becomes more isolated but may have cross-cutting changes across multiple separate repos. As the repos proliferate in the latter case, individual maintainers often become responsible for a larger number of repos and the other two problems impact them more. In summary, the mailing list solved a basic problem for a specific narrow use case at a time when technological constraints and solution options were very different than they are now. While the development/maintenance process can still be made to fit its usage, the large scale needs often no longer match, nor do the same technological restrictions apply. GitHub PRs aren't necessarily significantly better, but they do at least move the same concept to a place where an individual user/maintainer can keep their individual source of truth in one place (online), interact with it without needing a full development system/setup present, AND provides options for moving development processes in a new direction. The last has stagnated pretty badly, but throwing it out for a return to a system that has little to no options for modifying the process to meet modern needs seems overly agressive.

ddevault 6y ago

>is exactly why projects like Cairo suffer from lack of contributions I don't really agree with this. Many projects enjoy a vibrant development community on mailing lists today. Cairo suffers from different issues - and ultimately in Cairo's case it doesn't really matter. Cairo has been "done" for years, it's not the end of the world if it doesn't see much activity. >Do people really want to deal with text patches in 2020? Yes. You'll find many of them in this very thread. SourceHut is a brand-new service, only around for 2 years in alpha, and in 2020 alone it transacted 37,000 emails. There's obviously demand here. One thing that can matter a lot if you're trying out the email workflow is making sure you're using a good client. I made one that I recommend as such: https://aerc-mail.org https://aerc-mail.org. Other good choices include mutt and alpine.

Znafon 6y ago
Do you have a recommendation for a good GUI mail client?
- ddevault 6y ago
  Claws mail is pretty good IMO. There are some more options here: https://useplaintext.email https://useplaintext.email
  - Znafon 6y ago
    Thanks, last time I tested aerc I couldn't find a way to make it download all my mails locally. Is this possible?
    - Icyphox 6y ago
      Try mbsync or OfflineIMAP. Both great tools to sync a remote mailbox to local.
    - ddevault 6y ago
      No, but you can use it in combination with something like imapsync.
hvis 6y ago
Can you comment on individual lines of a changeset in an email and reply to such comments separately, and then see such conversations in the context of the diff? And then mark them as resolved when that happens? Can you read those discussions later in a "flat" presentation without scrolling through emails one-by-one? These are some of the killer features of the PR/MR Github/Gitlab workflows. To clarify, I'm talking about steps 4-7 here: https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request https://docs.github.com/en/free-pro-team@latest/github/colla... As well as the "Resolving conversations" section.
- ddevault 6y ago
  >Can you comment on individual lines of a changeset in an email and reply to such comments separately, and then see such conversations in the context of the diff? And then mark them as resolved when that happens? Yes, except for the last bit. Unlike GitHub/GitLab you can also respond to several comments at once. >Can you read those discussions later in a "flat" presentation without scrolling through emails one-by-one? I don't know what this means.
  - comex 6y ago
    Judging from my GitHub experience, I think they mean seeing, under each chunk of code, the whole conversation thread pertaining to that chunk. In other words, where a standard mailing list format looks like: Person 1 > Chunk of code 1 Comment > Chunk of code 2 Comment Person 2 > Chunk of code 1 Comment > Chunk of code 2 Comment they want a view like: Chunk of code 1 Person 1 Comment Person 2 Comment Chunk of code 2 Person 1 Comment Person 2 Comment
    - ddevault 6y ago
      Yeah, we have a view like that.
      - 6y ago
Qwertious 6y ago
"and in 2020 alone it transacted 37,000 emails. There's obviously demand here." Um, what? Suppose you have 10 developers sending an average of 10 emails a day. That's 100 * 365, or 36 500 emails a year. That stat doesn't sound very useful. 10 developers isn't demand.
- ddevault 6y ago
  Most projects on SourceHut don't receive anywhere near 10 patches per day. There are not any many large projects on sr.ht - established projects are slow to move off other platforms, and new projects haven't had a lot of time to gather steam. The top lists peak at like, 3 per day. What matters more is their volume: 1,447 of them were created in 2020.
nyanpasu64 6y ago
>Cairo has been "done" for years, it's not the end of the world if it doesn't see much activity. Cairo's fast antialiasing mode had a memory corruption bug that took 5 years after the bug report to be fixed. https://gitlab.freedesktop.org/cairo/cairo/-/issues/44 https://gitlab.freedesktop.org/cairo/cairo/-/issues/44

aaravchen 6y ago

For one, many corporate environments no longer directly tie email user identity and code user identity directly together, they frequently manage them thru a third service that both services connect to instead (e.g. OAuth, ActiveDirectory, etc). This also only works well if you have: 1) one commit per change, 2) every reviewer has a fully up to date copy of any/all repos being reviewed, 3) a single change only affects a single repo. The one-commit-per-change (squashed changes) is not always the preference, but it's effectively mandatory since the presentation format for patches only lends itself well to an isolated patch-diff and not a VCS history of changes (ironic since it's intended for the latter). As a great example of this, it's very difficult to compare the differences between the resulting code between two patches submitted to the same thread when I want to confirm a series of corrections to the original submissions were made properly and without side-effect. Every reviewer having a fully up-to-date copy of the repo the changes are going into works amazingly well for a fully distributed VCS, defining the gatekeeping maintainer's copy as the ultimate source of truth for the "latest". When multiple maintainers for the repo exist, as in most corporate environments and the monorepo organization, this breaks down. The ultimate source of truth for "latest" is now a remotely hosted repository that no one individual gatekeeps. Therefore all maintainers need to constantly duplicate the remote copy and keep it up to date. Either the maintainer is an active developer that's also creating changes constantly and will therefore need to keep two different copies so they can be building and testing their own development changes while keeping a pristine copy purely for review purposes, or they don't usually do a lot of active development themselves and keeping a local copy at all is purely for the purposes of review. In terms of pushing proliferation of copies of the distributed VCS it works, but when more (but not completely) centralized as most corporate environments/users need it's an extra hurdle that impedes the process rather than helping. For a single change to affect only a single repo requires at the extreme a monorepo layout, or an extremely well modularized design. As noted before, monorepo is very much against the design (few people should need a fully history copy of the entire repo locally with a monorepo, and many maintainers control the same repo) and defining sufficiently modularized breakdown is nigh impossible with larger projects. The Linux project is a great example of this problem, but has a semi-solution that involves having an even larger developer base involved at different levels of a heirarchy, and split repos for "modules" (independently maintained subcomponents or specialty areas) that have to manually cross-related. This is demonstrably problematic even now when a sub-area uses a separate repo and submits wholesale changes to the downstream project, losing almost all of the history and cross-linked-tracking information in so doing. Recognized as a common problem, the community has either gone the monorepo route where all changes go into the single larger repo at the cost of much greater coordination requirements, or the submodule-like route where each sub-part becomes more isolated but may have cross-cutting changes across multiple separate repos. As the repos proliferate in the latter case, individual maintainers often become responsible for a larger number of repos and the other two problems impact them more. In summary, the mailing list solved a basic problem for a specific narrow use case at a time when technological constraints and solution options were very different than they are now. While the development/maintenance process can still be made to fit its usage, the large scale needs often no longer match, nor do the same technological restrictions apply. GitHub PRs aren't necessarily significantly better, but they do at least move the same concept to a place where an individual user/maintainer can keep their individual source of truth in one place (online), interact with it without needing a full development system/setup present, AND provides options for moving development processes in a new direction. The last has stagnated pretty badly, but throwing it out for a return to a system that has little to no options for modifying the process to meet modern needs seems overly agressive.