4 ms·

Linus says of the Github platform - That's partly because of how the kernel is developed, but part of it was that the GitHub interfaces were actively encouragi

Linus says of the Github platform - That's partly because of how the kernel is developed, but part of it was that the GitHub interfaces were actively encouraging bad behavior. Commits done on GitHub had bad commit messages etc, because the web interfaces at GitHub were actively encouraging bad behavior. They did fix some of that, so it probably works better, but it will never be appropriate for something like the Linux kernel. I haven't ever looked at the kernel workflow, nor have I ever heard systematic criticism of Github's methodology. Does anyone else have input on what Linus may mean by his opinion?

merqumab 12y ago
See this 2012 thread https://github.com/torvalds/linux/pull/17#issuecomment-5654674 https://github.com/torvalds/linux/pull/17#issuecomment-56546...
rentnorove 12y ago
This pull request: https://github.com/torvalds/linux/pull/17 https://github.com/torvalds/linux/pull/17
gregkh 12y ago
The kernel development model is documented here: http://lxr.free-electrons.com/source/Documentation/development-process/ http://lxr.free-electrons.com/source/Documentation/developme... Github doesn't scale at all for large projects. The kernel is averaging over 8 changes an hour, 24 hours a day. That rate of change can never be handled by doing pull requests and web site review. It only can work with email and review and scriptable processes.
- quantumet 12y ago
  Eh, I mildly disagree on web site review. Perhaps not GitHub's pull request/review model, but big projects like Android and Chromium do all their review on web interfaces.
  - edejong 12y ago
    Using Gerrit, which is an automated mimick of Linus' development model. By the way, we've been succesfully using Gerrit on smaller-scale projects as well (around 8 change-requests / day) and don't even want to think about going back to pull-requests.
    - sunnyps 12y ago
      What you've said is essentially correct, but I'd like to make a minor correction: Chromium uses rietveld whereas Android (and some Chromium related projects) use gerrit. Rietveld and gerrit have similar workflows except that gerrit is more integrated with git (I think). Both are named after Gerrit Rietveld, a famous Dutch designer.
- wyldfire 12y ago
  But don't "trusted lieutenants" (yourself included?) mitigate a lot of the challenge posed by that high rate of change?
  - luckydude 12y ago
    Greg didn't reply but I think the answer is a resounding yes. I wrote this up a bit back when the devs were using BitKeeper. Lemme go find that. OK, ignore the "I want the 1995 era web pages" look and peek at this: http://www.mcvoy.com/lm/bitmover/lm/talks/socal/ http://www.mcvoy.com/lm/bitmover/lm/talks/socal/ tl;dr: fan in/fan out scales great if you have BitKeeper or Git.
- Touche 12y ago
  Can you explain what you mean? Why is email more "scalable" than a web interface?
- steveklabnik 12y ago
  We merged 473 PRs in Rust last month: https://github.com/rust-lang/rust/pulse/monthly https://github.com/rust-lang/rust/pulse/monthly That's roughly one every other hour, so still not quite on the same level. And we do use tooling _in addition_ to GitHub, but reviews are done in PR and not over email. (FWIW I personally wish more projects worked like the kernel's, but such is life)
- hamstergene 12y ago
  Just because one big project relies on emails does not mean they scale better. They work for the kernel because with that strong organization pretty much anything could work for the kernel. Criticisms in the interview were essentially about low discipline that Github interface allows, and how they were not willing to adapt to the kernel needs, not about fundamental deficiencies of pull request based model. So far nothing has been said about why pull requests via a website might handle less load than pull requests over email.
teamhappy 12y ago
> [...] nor have I ever heard systematic criticism of Github's methodology. He's not only criticizing Github: > (a) make a real pull request, not the braindamaged crap that github > does when you ask it to request a pull: real explanation, proper email > addresses, proper shortlog, and proper diffstat. > > (b) since github identities are random, I expect the pull request to > be a signed tag, so that I can verify the identity of the person in > question. Real explanation, proper shortlog, signed commit, etc. (Note that he didn't mention emojis.) All he seems to be asking for is that we take our time and do it properly. Makes all the sense in the world for a large, long-lived open source project like Linux. Imagine 20-year-old commit messages from FreeBSD would look like the ones we write today for, say, a npm module. --- edit --- Yeah ... nevermind. He explains it himself further down: > Btw, Joseph, you're a quality example of why I detest the github > interface. For some reason, github has attracted people who have zero > taste, don't care about commit logs, and can't be bothered. > > The fact that I have higher standards then makes people like you make > snarky comments, thinking that you are cool. > > You're a moron. > > Linus
- GFK_of_xmaspast 12y ago
  "You're a moron." That's our Linus-kun.
  - rdtsc 12y ago
    Well he was a moron. Linus is Linus-kun because often he is right. Here is more of the exchange for context: --- Umm. Notice how the "Joseph" I replied to had deleted all the comments he wrote? That should tell you something. I smacked down a troll. If I was polite to you all those years ago, and I was polite but firm in the two first responses, please give me credit for when I smack somebody down. There may be a reason for it. The fact that the person deleted his messages (or github deleted them for him - I have no idea what their comment policy is) and you cannot see that context any more online should not make you think that I suddenly went crazy. Btw, since I get the github messages in email too, I have a copy. Joseph replied to those "polite but firm" messages where I explained exactly why I don't want to bother with github pull requests with this gem: "I did not realizes that Linus' shit does not stink. Thanks for clearing that up..." ---
davexunit 12y ago
I was so happy to read this. I completely agree with Linus' criticisms of the pull request system that GitHub has popularized. They've deeply embedded really bad habits into programmers. I used to wonder "Why do some projects still do patch review on a mailing list?" and then I realized it was for the reasons that Linus gave here.
- mushly 12y ago
  So what's the best way to do it instead? And why is the current model so bad?

merqumab 12y ago

See this 2012 thread https://github.com/torvalds/linux/pull/17#issuecomment-5654674 https://github.com/torvalds/linux/pull/17#issuecomment-56546...

rentnorove 12y ago

This pull request: https://github.com/torvalds/linux/pull/17 https://github.com/torvalds/linux/pull/17

gregkh 12y ago

The kernel development model is documented here: http://lxr.free-electrons.com/source/Documentation/development-process/ http://lxr.free-electrons.com/source/Documentation/developme... Github doesn't scale at all for large projects. The kernel is averaging over 8 changes an hour, 24 hours a day. That rate of change can never be handled by doing pull requests and web site review. It only can work with email and review and scriptable processes.

quantumet 12y ago
Eh, I mildly disagree on web site review. Perhaps not GitHub's pull request/review model, but big projects like Android and Chromium do all their review on web interfaces.
- edejong 12y ago
  Using Gerrit, which is an automated mimick of Linus' development model. By the way, we've been succesfully using Gerrit on smaller-scale projects as well (around 8 change-requests / day) and don't even want to think about going back to pull-requests.
  - sunnyps 12y ago
    What you've said is essentially correct, but I'd like to make a minor correction: Chromium uses rietveld whereas Android (and some Chromium related projects) use gerrit. Rietveld and gerrit have similar workflows except that gerrit is more integrated with git (I think). Both are named after Gerrit Rietveld, a famous Dutch designer.
wyldfire 12y ago
But don't "trusted lieutenants" (yourself included?) mitigate a lot of the challenge posed by that high rate of change?
- luckydude 12y ago
  Greg didn't reply but I think the answer is a resounding yes. I wrote this up a bit back when the devs were using BitKeeper. Lemme go find that. OK, ignore the "I want the 1995 era web pages" look and peek at this: http://www.mcvoy.com/lm/bitmover/lm/talks/socal/ http://www.mcvoy.com/lm/bitmover/lm/talks/socal/ tl;dr: fan in/fan out scales great if you have BitKeeper or Git.
Touche 12y ago
Can you explain what you mean? Why is email more "scalable" than a web interface?
steveklabnik 12y ago
We merged 473 PRs in Rust last month: https://github.com/rust-lang/rust/pulse/monthly https://github.com/rust-lang/rust/pulse/monthly That's roughly one every other hour, so still not quite on the same level. And we do use tooling _in addition_ to GitHub, but reviews are done in PR and not over email. (FWIW I personally wish more projects worked like the kernel's, but such is life)
hamstergene 12y ago
Just because one big project relies on emails does not mean they scale better. They work for the kernel because with that strong organization pretty much anything could work for the kernel. Criticisms in the interview were essentially about low discipline that Github interface allows, and how they were not willing to adapt to the kernel needs, not about fundamental deficiencies of pull request based model. So far nothing has been said about why pull requests via a website might handle less load than pull requests over email.

teamhappy 12y ago

> [...] nor have I ever heard systematic criticism of Github's methodology. He's not only criticizing Github: > (a) make a real pull request, not the braindamaged crap that github > does when you ask it to request a pull: real explanation, proper email > addresses, proper shortlog, and proper diffstat. > > (b) since github identities are random, I expect the pull request to > be a signed tag, so that I can verify the identity of the person in > question. Real explanation, proper shortlog, signed commit, etc. (Note that he didn't mention emojis.) All he seems to be asking for is that we take our time and do it properly. Makes all the sense in the world for a large, long-lived open source project like Linux. Imagine 20-year-old commit messages from FreeBSD would look like the ones we write today for, say, a npm module. --- edit --- Yeah ... nevermind. He explains it himself further down: > Btw, Joseph, you're a quality example of why I detest the github > interface. For some reason, github has attracted people who have zero > taste, don't care about commit logs, and can't be bothered. > > The fact that I have higher standards then makes people like you make > snarky comments, thinking that you are cool. > > You're a moron. > > Linus

GFK_of_xmaspast 12y ago
"You're a moron." That's our Linus-kun.
- rdtsc 12y ago
  Well he was a moron. Linus is Linus-kun because often he is right. Here is more of the exchange for context: --- Umm. Notice how the "Joseph" I replied to had deleted all the comments he wrote? That should tell you something. I smacked down a troll. If I was polite to you all those years ago, and I was polite but firm in the two first responses, please give me credit for when I smack somebody down. There may be a reason for it. The fact that the person deleted his messages (or github deleted them for him - I have no idea what their comment policy is) and you cannot see that context any more online should not make you think that I suddenly went crazy. Btw, since I get the github messages in email too, I have a copy. Joseph replied to those "polite but firm" messages where I explained exactly why I don't want to bother with github pull requests with this gem: "I did not realizes that Linus' shit does not stink. Thanks for clearing that up..." ---

davexunit 12y ago

I was so happy to read this. I completely agree with Linus' criticisms of the pull request system that GitHub has popularized. They've deeply embedded really bad habits into programmers. I used to wonder "Why do some projects still do patch review on a mailing list?" and then I realized it was for the reasons that Linus gave here.

mushly 12y ago
So what's the best way to do it instead? And why is the current model so bad?