(I work at GitHub.)<p>Linus wrote into github support with some good and pointed feedback as well, most of which was related to email sent when a pull request is opened vs. what you might expect to see when someone submits a patch series to a mailing list. I assume this is what he's referring to with, "so from the pull request it's actually hard to see <i>what</i> somebody asks you to pull," in the quoted bit from the article. We have some changes lined up that we hope will address this.<p>As for the quality of pull requests, it's unfortunate that a people took this as an opportunity to troll (<a href="https://github.com/torvalds/linux/pull/6" rel="nofollow">https://github.com/torvalds/linux/pull/6</a>). That will hopefully settle down once this is no longer "news". If not, we'll find a way to a address it.<p>Lastly, it's worth noting that the linux-kernel mailing list -- where the majority of linux related development and discussion happens -- is an open list (i.e. doesn't require subscribing / passing moderation to post). The ability for anyone to send a pull request to anyone at any time on GitHub is based somewhat on the success of open-list policies on projects like the kernel. While we're always looking for ways to help with trolls, the basic model isn't something we think needs to be "fixed".
In my humble opinion, GitHub should bend over backwards to get this to work for him. Project admins really need better control over who can create pull requests, and what they should look like.
"Together with making it trivial to create commits and pull requests entirely in the browser"<p>Isn't that a /good/ thing? The main hurdle I find when trying to fix problems in open source projects is working out how to submit my patch in a way which minimises the effort for the developer who has to review/merge it. As someone who has made and accepted pull requests, GitHub makes the process of accepting contributions about as easy as it can be.<p>With regards to poor-quality requests, that's something you have to accept as part of a project, just like poor-quality bug reports.
Seems to be down. Google to rescue: <a href="http://webcache.googleusercontent.com/search?q=cache:http://blueparen.com/node/12" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:http://...</a>
Google Cache version
<a href="http://webcache.googleusercontent.com/search?q=cache:blueparen.com/node/12&hl=en&strip=1" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:bluepar...</a>
For those that didn't see, Issues were enabled on Linus' Linux kernel GitHub project for a short while. In barely any time at all, an issue appeared -- some trolling along the lines of "Can't run M$ Office", followed by a bunch of amused +1s and BLATANTLYAVIRUS.EXE gags.<p>So I can see why he has some trepidation about the GitHub Issues system -- it is a little too easy to troll, and the signal/noise ratio isn't, uh, quite what he's used to.
Comments seem to be Linus' style but is there some way to confirm these are really Linus' thoughts on GitHub? Linus hasn't said anything, for example, on his G+ account, which he used to report about the kernel hosting issue...<p><a href="https://plus.google.com/102150693225130002912/posts/PVZDD2N3Tvi" rel="nofollow">https://plus.google.com/102150693225130002912/posts/PVZDD2N3...</a>