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 what somebody asks you to pull," in the quoted bit from the article. We have some changes lined up that we hope will address this.
As for the quality of pull requests, it's unfortunate that a people took this as an opportunity to troll (https://github.com/torvalds/linux/pull/6). That will hopefully settle down once this is no longer "news". If not, we'll find a way to a address it.
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.
I'd be pretty leery of limiting who can send pull requests, but what Github needs to do is make it very clear that the big "merge pull request" button is usually a BAD idea unless it's a doc-only change. They should
- create a branch or tag containing the merge so that it's easy to pull the change without having to add additional remotes.
- provide instructions on how to pull, merge and push the request saying explicitly that the merge should be inspected and tested before doing the push.
- make the latter more obvious to click than "merge pull request" button
EDIT: I'm not saying that Linus needs this, but responding to Linus' comment about it being much too easy to do poor-quality commits.
I think it would be nice if "pulling" would create a new branch (with a specifiable name) per default so that you can run tests and merge to master locally.
Well, he already has a dedicated team of admins who've set up a system for him - kernel.org. He's only using github temporarily until his usual system comes back online. It'd be a bit of a shame for Github to go to all that effort only to have Linus abandon his account by the end of the week.
Hardly, he maintains probably one of the biggest git based source controlled projects in the world. If he has these issues then it's likely that using the advice to improve upon the current system will also benefit others running sizeable projects and attract more large customers.
"Together with making it trivial to create commits and pull requests entirely in the browser"
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.
With regards to poor-quality requests, that's something you have to accept as part of a project, just like poor-quality bug reports.
It's a good thing for most open source projects, which are starved for attention. It's probably not a good thing for an extremely popular project like Linux.
If a project is very popular, something which makes it easier to handle pull requests is surely a good thing as well? That way developers spend more time coding and less time on review/merging (not that those aren't important tasks, but it seems sensible to streamline them if possible).
I think the key feature would be something more along the lines of, "easier to handle pull requests that are required to be structured in specific ways" and "able to see exactly what a pull request will do".
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.
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...
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 what somebody asks you to pull," in the quoted bit from the article. We have some changes lined up that we hope will address this.
As for the quality of pull requests, it's unfortunate that a people took this as an opportunity to troll (https://github.com/torvalds/linux/pull/6). That will hopefully settle down once this is no longer "news". If not, we'll find a way to a address it.
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".