10 ms·

How bizarre (1) that the author doesn't accept Pull Requests. I'd love to know more about why .patch files via mailing list are preferred. 1) adjective . stran

How bizarre (1) that the author doesn't accept Pull Requests. I'd love to know more about why .patch files via mailing list are preferred. 1) adjective . strange or unusual, especially so as to cause interest or amusement.

ubertaco 5y ago
I wonder if it's a "raised barrier to entry" to prevent low-effort drive-by PRs. I have a couple of extremely-small OSS libs that are available in public package repos and are hosted on Github, and even those have gotten the drive-by "I slightly reworded your README" PRs that don't help. I can't imagine the volume of noise that larger projects get. By requiring a .patch file to be sent via a mailing list, the sort of "burden of effort" shifts away from "log into Github and click the pencil icon in the preview for README.md" and towards a slightly-heavier-weight minimum threshold -- one that shouldn't be so bad as to discourage folks making earnest valuable changes, but might be enough to make low-effort spam more annoying for the spammer than the spam-ee.
- andrew_ 5y ago
  Barrier of entry is a good call. From my experience on some rather large OSS projects, the ratio of noise to signal on PRs tends to go along with the target audience of the project.
- londons_explore 5y ago
  Mailing lists suffer from other kinds of spam... Actual email spam, poor moderation tools, etc.
qbasic_forever 5y ago
It's how git was created to operate. The linux kernel, probably the largest software project in history, only operates through emailed patch files too.
- cxr 5y ago
  Linux uses pull requests, too, it's just that it uses them the way they were meant to be used—among a limited cohort of collaborators frequently pulling from one another—instead of GitHub-style pull requests that have little to do with Git-the-tool and that everyone gets shunted through, even when a patch (or three) would be more appropriate.
- charcircuit 5y ago
  Windows is bigger than Linux and they don't use a mailing list workflow with git.
  - cxr 5y ago
    Code size is not what the other commenter was referring to when they wrote "largest". There are of course other projects with more LOC than the Linux kernel.
cxr 5y ago
Using a mailing list to manage (incl. browse) contributions really sucks. The way that GitHub abuses pull requests and all the anti-productive derpiness that has arisen around it, though, sucks even more. It will be nice when the world gets shaken out of the collective hallucination that GitHub is at all a reasonable and efficient way to do things, instead of what it actually is: another dark-pattern-employing, walled garden social network that prioritizes engagement and growth over productivity, privacy, accessibility, and quality of interaction.
- pcwalton 5y ago
  The pull request workflow is not "anti-productive derpiness". You literally click one button and the pull request is merged. With email you have to save the patch from your webmail client† somewhere, then apply it on the command line, and then push your changes. This workflow inefficiency is multiplied by the number of patches you have and therefore adds up quickly. There is no good reason for it other than nostalgia for the old days of Unix when everything was email based because the Web wasn't very mature yet. †Yes, most people use webmail, not native desktop email clients, and no, it is not reasonable to expect people to switch for this.
  - carapace 5y ago
    You're arguing the old argument CLI/Terminal vs. GUI. Clicking a button vs. typing some commands is not the productivity bottleneck (or if it is you have bigger problems, eh?) (I've seen terminal jockeys do things that blew my mind, emitting continuous streams of characters that seamlessly switched between terminals and functions, orchestrating their machine like some virtuoso pianist, moving so fast it was impossible to follow. GUIs offer such folk nothing and I wouldn't be surprised if Fabrice Bellard was of this ilk.)
  - badsectoracula 5y ago
    As a contributor i found sending (or attaching to a bug report) .patch files much easier than the pull request-based workflow, especially when there are changes after the patch is made.
  - 5y ago

ubertaco 5y ago

I wonder if it's a "raised barrier to entry" to prevent low-effort drive-by PRs. I have a couple of extremely-small OSS libs that are available in public package repos and are hosted on Github, and even those have gotten the drive-by "I slightly reworded your README" PRs that don't help. I can't imagine the volume of noise that larger projects get. By requiring a .patch file to be sent via a mailing list, the sort of "burden of effort" shifts away from "log into Github and click the pencil icon in the preview for README.md" and towards a slightly-heavier-weight minimum threshold -- one that shouldn't be so bad as to discourage folks making earnest valuable changes, but might be enough to make low-effort spam more annoying for the spammer than the spam-ee.

andrew_ 5y ago
Barrier of entry is a good call. From my experience on some rather large OSS projects, the ratio of noise to signal on PRs tends to go along with the target audience of the project.
londons_explore 5y ago
Mailing lists suffer from other kinds of spam... Actual email spam, poor moderation tools, etc.

qbasic_forever 5y ago

It's how git was created to operate. The linux kernel, probably the largest software project in history, only operates through emailed patch files too.

cxr 5y ago
Linux uses pull requests, too, it's just that it uses them the way they were meant to be used—among a limited cohort of collaborators frequently pulling from one another—instead of GitHub-style pull requests that have little to do with Git-the-tool and that everyone gets shunted through, even when a patch (or three) would be more appropriate.
charcircuit 5y ago
Windows is bigger than Linux and they don't use a mailing list workflow with git.
- cxr 5y ago
  Code size is not what the other commenter was referring to when they wrote "largest". There are of course other projects with more LOC than the Linux kernel.

cxr 5y ago

Using a mailing list to manage (incl. browse) contributions really sucks. The way that GitHub abuses pull requests and all the anti-productive derpiness that has arisen around it, though, sucks even more. It will be nice when the world gets shaken out of the collective hallucination that GitHub is at all a reasonable and efficient way to do things, instead of what it actually is: another dark-pattern-employing, walled garden social network that prioritizes engagement and growth over productivity, privacy, accessibility, and quality of interaction.

pcwalton 5y ago
The pull request workflow is not "anti-productive derpiness". You literally click one button and the pull request is merged. With email you have to save the patch from your webmail client† somewhere, then apply it on the command line, and then push your changes. This workflow inefficiency is multiplied by the number of patches you have and therefore adds up quickly. There is no good reason for it other than nostalgia for the old days of Unix when everything was email based because the Web wasn't very mature yet. †Yes, most people use webmail, not native desktop email clients, and no, it is not reasonable to expect people to switch for this.
- carapace 5y ago
  You're arguing the old argument CLI/Terminal vs. GUI. Clicking a button vs. typing some commands is not the productivity bottleneck (or if it is you have bigger problems, eh?) (I've seen terminal jockeys do things that blew my mind, emitting continuous streams of characters that seamlessly switched between terminals and functions, orchestrating their machine like some virtuoso pianist, moving so fast it was impossible to follow. GUIs offer such folk nothing and I wouldn't be surprised if Fabrice Bellard was of this ilk.)
- badsectoracula 5y ago
  As a contributor i found sending (or attaching to a bug report) .patch files much easier than the pull request-based workflow, especially when there are changes after the patch is made.
- 5y ago