

Linus Torvalds Comments About Github - mudge
http://blueparen.com/node/12

======
rtomayko
(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".

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

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

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

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

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

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

------
anton_gogolev
Seems to be down. Google to rescue:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://blueparen.com/node/12)

------
runn1ng
Google Cache version
[http://webcache.googleusercontent.com/search?q=cache:bluepar...](http://webcache.googleusercontent.com/search?q=cache:blueparen.com/node/12&hl=en&strip=1)

~~~
mudge
It is back up now.

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

------
javipas
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...](https://plus.google.com/102150693225130002912/posts/PVZDD2N3Tvi)

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

------
judofyr
It's down here. Mirror anyone?

