Linus Torvalds Comments About Github

by mudge • 15 years ago

34 20 15 years ago

mstroeck2• 15 years ago

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.

thristian• 15 years ago

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.

ptn• 15 years ago

Linus' feedback would make GitHub ready to support larger projects, regardless of the kernel staying or not.

Supporting larger projects can't be a bad thing, that wouldn't be wasted effort.

robryan• 15 years ago

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.

bryanlarsen• 15 years ago

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.

greyfade• 15 years ago

That sounds like exactly what Linus does with pull requests on LKML.

DasIch• 15 years ago

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.

judofyr• 15 years ago

It's down here. Mirror anyone?

runn1ng• 15 years ago

Google Cache version http://webcache.googleusercontent.com/search?q=cache:bluepar...

mudge2• 15 years ago

It is back up now.

anton_gogolev• 15 years ago

Seems to be down. Google to rescue: http://webcache.googleusercontent.com/search?q=cache:http://...

javipas• 15 years ago

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...

https://plus.google.com/102150693225130002912/posts/PVZDD2N3...

mudge2• 15 years ago

I personally emailed Linus and posted his response. My name is Nick Mudge in case anyone wants to publicly call me a liar.

pwaring2• 15 years ago

"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.

streptomycin• 15 years ago

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.

pwaring2• 15 years ago

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).

rtomayko• 15 years ago

(I work at GitHub.)

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".

orls• 15 years ago

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.

Linus Torvalds Comments About Github

Related Stories