5 ms·

I always wondered how managing patches/patchsets using mail could scale. Now we know: It does not. I believe this calls not for a separate mailing list but a p

by fuzzy2 3y ago

I always wondered how managing patches/patchsets using mail could scale. Now we know: It does not. I believe this calls not for a separate mailing list but a proper solution, whatever that might be.

yakubin 3y ago
The problem here is that lots of patches are sent to too many people. Same will happen if you CC a mailing list with many subscribers in patches sent to Gerrit[1] or GitHub for a vibrant project. People will just start ignoring those notifications. It’s not about the tool. [1]: Speaking as a Gerrit fan.
- KennyBlanken 3y ago
  The problem would be easily solved by: 1)Requiring the patch be posted online somewhere, not in the email message as an attachment. Criteria could be set, such as "must be via https, and something that will handle the volume of hits without becoming unreachable due to insufficient quota, server resources, or quota." Or set up a patch hosting server. Etc. 2)Dividing the kernel into major categories like every other major open source software project, and having patch lists for those categories. The main list should only be for announcements and discussions that require a broad audience.
  - CuriousCosmic 3y ago
    > 2)Dividing the kernel into major categories like every other major open source software project, and having patch lists for those categories. The main list should only be for announcements and discussions that require a broad audience. Uhhhh the linux kernel mailing list is made up of at least a hundred separate mailing lists with development happening on the more specific mailing lists and a focus on maintaining/integration occurring on the more general lists.
    - seba_dos1 3y ago
      Did you expect a HN commenter to actually research the thing they're commenting on? :P
TylerE 3y ago
Mailing lists are like XML. Whatever the original problem was, you now have two problems.
- m463 3y ago
  mailing lists are democratic/agnostic
  - leonheld 3y ago
    How is a self-hosted GitLab instance less democratic than e-mail? The only difference between the two is that one is a major PITA to setup as a user.
XorNot 3y ago
Isn't the primary and possibly only objection to GitHub PRs just that they don't allow individual commit commenting?
- mdaniel 3y ago
  GH for sure allows commentary on individual commits (e.g. <https://github.com/torvalds/linux/commit/23816724fdbd47c28bc998866fd7bc5ad9f0e535#all_commit_comments https://github.com/torvalds/linux/commit/23816724fdbd47c28bc...>) but they do not automatically roll up to the top-level PR view (since, how would that work with cherry-picks: it shows up in every PR? what if, as is more likely, the line were superseded in a subsequent commit?)
  - seba_dos1 3y ago
    How are cherry-picks relevant? Cherry-picking creates completely separate and topologically unrelated commits. GitLab handles comments on commits within MRs pretty well. It still doesn't make it adequate for projects like Linux though.
- CuriousCosmic 3y ago
  Github PRs do not make it easy for you to sign merge commits. It's possible in gitlab to my knowledge but in github it's a pain in the ass. And github needlessly touches PR commits so that even if you could fast-forward merge/rebase the PR while keeping signatures in tact, github will still regenerate your commits, breaking the hashes and signatures.
- aseipp 3y ago
  No, it's not enough. One of the most important features missing is that kernel developers will want the equivalent of `git range-diff` (i.e. the ability to compare two versions of a single commit which was submitted as part of a batch of commits) in the UX for code review purposes. The lack of this feature makes the entire thing a non-starter, both Github and Gitlab. That said, they have accepted some PRs on GitHub at the past at one point as an experiment IIRC. But no, the current features they want are not there. The only real practical alternative is probably something like Gerrit, which still probably is missing features they want, or to write their own patch review tool on top of lore.lkml.org and some other infra.
tleb_ 3y ago
Well it has scaled up until now, which is a sign it could fit the scale of almost all software projects.

by fuzzy2 3y ago

I always wondered how managing patches/patchsets using mail could scale. Now we know: It does not. I believe this calls not for a separate mailing list but a proper solution, whatever that might be.

yakubin 3y ago

The problem here is that lots of patches are sent to too many people. Same will happen if you CC a mailing list with many subscribers in patches sent to Gerrit[1] or GitHub for a vibrant project. People will just start ignoring those notifications. It’s not about the tool. [1]: Speaking as a Gerrit fan.

KennyBlanken 3y ago
The problem would be easily solved by: 1)Requiring the patch be posted online somewhere, not in the email message as an attachment. Criteria could be set, such as "must be via https, and something that will handle the volume of hits without becoming unreachable due to insufficient quota, server resources, or quota." Or set up a patch hosting server. Etc. 2)Dividing the kernel into major categories like every other major open source software project, and having patch lists for those categories. The main list should only be for announcements and discussions that require a broad audience.
- CuriousCosmic 3y ago
  > 2)Dividing the kernel into major categories like every other major open source software project, and having patch lists for those categories. The main list should only be for announcements and discussions that require a broad audience. Uhhhh the linux kernel mailing list is made up of at least a hundred separate mailing lists with development happening on the more specific mailing lists and a focus on maintaining/integration occurring on the more general lists.
  - seba_dos1 3y ago
    Did you expect a HN commenter to actually research the thing they're commenting on? :P

TylerE 3y ago

Mailing lists are like XML. Whatever the original problem was, you now have two problems.

m463 3y ago
mailing lists are democratic/agnostic
- leonheld 3y ago
  How is a self-hosted GitLab instance less democratic than e-mail? The only difference between the two is that one is a major PITA to setup as a user.

XorNot 3y ago

Isn't the primary and possibly only objection to GitHub PRs just that they don't allow individual commit commenting?

mdaniel 3y ago
GH for sure allows commentary on individual commits (e.g. <https://github.com/torvalds/linux/commit/23816724fdbd47c28bc998866fd7bc5ad9f0e535#all_commit_comments https://github.com/torvalds/linux/commit/23816724fdbd47c28bc...>) but they do not automatically roll up to the top-level PR view (since, how would that work with cherry-picks: it shows up in every PR? what if, as is more likely, the line were superseded in a subsequent commit?)
- seba_dos1 3y ago
  How are cherry-picks relevant? Cherry-picking creates completely separate and topologically unrelated commits. GitLab handles comments on commits within MRs pretty well. It still doesn't make it adequate for projects like Linux though.
CuriousCosmic 3y ago
Github PRs do not make it easy for you to sign merge commits. It's possible in gitlab to my knowledge but in github it's a pain in the ass. And github needlessly touches PR commits so that even if you could fast-forward merge/rebase the PR while keeping signatures in tact, github will still regenerate your commits, breaking the hashes and signatures.
aseipp 3y ago
No, it's not enough. One of the most important features missing is that kernel developers will want the equivalent of `git range-diff` (i.e. the ability to compare two versions of a single commit which was submitted as part of a batch of commits) in the UX for code review purposes. The lack of this feature makes the entire thing a non-starter, both Github and Gitlab. That said, they have accepted some PRs on GitHub at the past at one point as an experiment IIRC. But no, the current features they want are not there. The only real practical alternative is probably something like Gerrit, which still probably is missing features they want, or to write their own patch review tool on top of lore.lkml.org and some other infra.

tleb_ 3y ago

Well it has scaled up until now, which is a sign it could fit the scale of almost all software projects.