10 ms·

Golang Proposal: Just Use GitHub

68 points by ahacker15 9y ago

grabcocque 9y ago
I wonder if Google really loves Gerrit, or if it’s just a legacy NIH attachment and some of Google’s graybeards just refuse to let it go. Having worked with Gerrit in the past, I can say without a shadow of a doubt, it’s an abomination and I’d lop off a limb rather than voluntarily use Gerrit again.
- dannyw 9y ago
  Do you really think Google can really put their whole development and review infrastructure into the hands of a relatively small company named GitHub? The same platform where you see "GitHub is down" on HN every couple of months?
  - hellofunk 9y ago
    Well, Apple has done a lot of it with Swift. Language evolution discussions and the code itself is on GH.
  - coldtea 9y ago
    >The same platform where you see "GitHub is down" on HN every couple of months? Because Google's internal and external services don't go down? Ever tried GAE?
gksmythe 9y ago
The tyranny of GitHub. GitHub pull requests are one of the most cumbersome ways of contributing to OSS. What people really like is: a) The paper trail (I can show to my career manager that I've done some work). b) The constant distractions that feel like work. c) Minor issues seem like major contributions. d) Self promotion.
- matt4077 9y ago
  This is insane, considering the process before github was "send a patch by email". Hundreds of thousands of people, including me, have started contributing patches because the Github process has a much lower barrier to entry, is standardised, and effortlessly teaches you how to do it when you browse around a project.
maaaats 9y ago
Kinda scary how de facto Github has become, that external tooling is discouraged. Github is a bad issue tracker, a bad code review tool, an ok wiki and a bad distribution platform. Still, one has to mostly use the whole package to get contributors. (Github has other strengths, though)
- giancarlostoro 9y ago
  BitBucket is plenty popular as well, I run into projects that are on there instead of GH for Python. I kind of prefer BitBucket to GitHub the only thing GitHub does right is their "Explore" section which I don't think BitBucket has (or GitLab?) but that's about it for me. I don't care where one hosts code, as long as it's not some obscure server.
  - matwood 9y ago
    For a long time BitBucket was the only one with the protected branch feature that could prevent history rewrites on a branch by branch basis. Github finally added it after the force push that blew away so many critical repositories. BitBucket also has free private repos. I only use GH for projects that are open source because that's where people expect OSS to be.
    - StavrosK 9y ago
      I use Gitlab and just have it push to Github, then disable issues/wiki/whatever else I can there, and add a link to the Gitlab repo in the description.
  - hellofunk 9y ago
    GitHub has always had far superior code search features. BitBucket is gradually trying to add these, but they still pale compared to GitHub. I love just going through a repo by searching for things.
    - giancarlostoro 9y ago
      Except for when you want to search within a different branch.
shadowmint 9y ago
Unfortunately the epic comment thread, very talky, none of the key stack holders involved, largely irrelevant chatter... Is a case in point of why github isn't the answer for everything.
- Tade0 9y ago
  Wow, a proper use of the word "epic". I thought the original meaning was gone.
  - coldtea 9y ago
    I doubt the GitHub thread was "a long poem, typically one derived from ancient oral tradition, narrating the deeds and adventures of heroic or legendary figures or the past history of a nation"
    - Tade0 9y ago
      You're confusing a noun with an adjective. As an adjective it's something that's "extending beyond the usual or ordinary especially in size or scope".
      - matt4077 9y ago
        The adjective is obviously. derived from the noun, and as such had much of the same meaning originally: "relating to or characteristic of an epic or epics: our national epic poem Beowulf." And no, I'm not proud of having to weigh in on this subject.
      - coldtea 9y ago
        epic, adjective 1. relating to or characteristic of an epic or epics. 2. heroic or grand in scale or character. "his epic journey around the world" You were saying?
        Tade0 9y ago
        Citation needed. Here's my source: https://www.merriam-webster.com/dictionary/epic https://www.merriam-webster.com/dictionary/epic
dmitriid 9y ago
Ah, the joys of a distributed version control system: let's put all code on GitHub and depend on it for everything.
- mbrock 9y ago
  The joy of decentralization to my mind is not a total avoidance of centers, it is resilience against those centers becoming obnoxiously or harmfully authoritative. Because Git is already thoroughly decentralized in its architecture, I'm not particularly afraid of GitHub, though I rely on it daily. I know that I can migrate from it without any fundamental problems. Development workflows are decoupled from their servers in a robust way. Commit hashes and GPG signatures mean that GitHub is not really a trusted central point, but a useful hub. Issue tracking is centralized on GitHub, and that's the biggest problem with it. Maybe that's a lock-in strategy from GitHub the corporation, although the APIs do allow migration.
- frou_dh 9y ago
  Well it can be a pure win. As long as GitHub is used as a "dumb" git host that's just another node in the network. As you mentioned, the dubious part is if it captures control of all of your "meta" processes too.
nascent10 9y ago
The proposal comments are a wave of silly millennial entitlement. GitHub has ruined software development for adults.
rectang 9y ago
In my experience, there are no debates so fraught and vicious as those over version control platforms. Questions of more open governance for Go really ought to be separated from Github specifically. Moving from googlesource to Gitlab or Bitbucket would achieve the same thing. Which is actually not much: just because a project is on a given commercial hosting platform doesn't portend a change in how decisions get made over project direction, as many projects hosted on Github (and Gitlab and Bitbucket) illustrate.
deleted 9y ago
[deleted]
dis-sys 9y ago
the proposal is cute and funny, basically the author argues that to make the contribution and governance process more open, everything has to be done on github to be more closely aligned with what project X,Y,Z are doing. that is not open or free, that is the exact opposite of being free and open.
- coldtea 9y ago
  Open as in actually welcoming and convenient for people to participate. Not in the religious/GNU sense.
alenmilk 9y ago
From the comments on the page: jimmyfrasche commented The language spec is easier to read than the contribution guidelines
arkadiytehgraet 9y ago
If one cannot figure out how to setup a development environment (with detailed guides), how can one be expected to actually make a meaningful contribution in a much more difficult domain like compiler development? For this purpose alone I think the current approach is something that Google will not get rid of. Moreover, why on Earth would Google want to create an external dependency for code-hosting and development like GitHub, that may go down anytime, making them lose a lot of time and money, especially since their own system is much more reliable (at least for internal usage) and they have all resources they need to maintain it? Finally, it is somewhat really silly to think that a giant corp like Google will develop something truly free and opensource, without their own interests above anything else, which obviously will become an issue sooner or later with the truly freedom spirit.
- _asummers 9y ago
  The article addresses how Google is already using GitHub with Kubernetes. Looks like Dart does too from glancing through the GitHub. If you're worried about external services going down, you make an internal mirror. You don't force the whole workflow to go through your system.
  - arkadiytehgraet 9y ago
    Or you just don't use an external service in the first place, minimizing your dependencies, which you arguably should be doing anyway? They are not forcing anyone to go through their system, it is completely your choice to either help the project or not.
- lloeki 9y ago
  > If one cannot figure out how to setup a development environment (with detailed guides), how can one be expected to actually make a meaningful contribution in a much more difficult domain like compiler development? Because those are two unrelated fields, and one is distinctly not productive. From the issue: > I ran through the contributing workshop at Gophercon 2017. I even had gone through half of it before. I still needed help from one of the guides. It was still arduous. I speak as someone who has written Go professionally 40 hours a week for over 4 years - the contribution workflow deters me from contributing to the Go project. Even after signing up. The fact that it's so different from my everyday workflow just makes the hill to climb too steep. And comments (from current contributors no less): > I've been writing Go for over five years and contributing in various forms, and I have to say I agree. go-contrib-init makes things better, but the barrier to contributing to Go is a lot higher and with a different workflow from almost any other project that uses Go. > As successful as the contributor workshop at Gophercon was, it is an embarrassment to the language that we had to do it at all. Why did we need an entire seminar to teach hundreds of developers who already contribute to many other open source projects how to contribute to Go? Also, not every contribution to Go involves mucking with the compiler. > why on Earth would Google want to create an external dependency for code-hosting and development like GitHub Didn't they move to Google Code to GitHub, which is the live repo, Gerrit being used for code review only? If so, the dependency is already there. If not, why is it on GitHub at all? > Finally, it is somewhat really silly to think that a giant corp like Google will develop something truly free and opensource, without their own interests above anything else, which obviously will become an issue sooner or later with the truly freedom spirit. I think somehow this is tackled by the issue author, and is a canary of sorts: > Let's show the OSS world that Go really is a community-run project
hellofunk 9y ago
If one wants to see the merits or at least the experiences of a major language from a commercial entity going open source on GitHub, where all discussions, language features, issues, and code itself is in that one place, take a look at Apple's Swift. Edit: Looks like Swift doesn't use GH for issues any more.
- andrewnez 9y ago
  Swift switched all their issue tracking to Jira a while back
- Androider 9y ago
  Swift doesn't seem to be using GitHub's issue tracker, wikis or anything except the code hosting really.
  - hellofunk 9y ago
    Well they use code files for discussions, so it's a bit different.
speps 9y ago
I've contributed a small patch to Go not that long ago and it was quite straightforward, I don't get why it has to be changed. Plenty of people have used the current workflow for years now...
hamax 9y ago
It's true that Gerrit's workflow is a bit unusual, but even though I had no experience with it, I managed to setup the environment and create a review request for Golang in under an hour. When it comes to contributing to a programming language, I think this is pretty friction-less. CLA was very painless too.
- IshKebab 9y ago
  An hour is pretty bad don't you think? Pretty sure it would be quicker with github.
  - hamax 9y ago
    Sure it would be. Mostly because I use Github every day. The first time I tried to create a pull request it probably took me almost as much time to figure out how Github works. But compared how much time is saved for reviewers by having a better tool, I think 1 hour for each new contributor is reasonable.
TurboHaskal 9y ago
Hi PCJ!
Sir_Cmpwn 9y ago
The "just use GitHub" mentality is harmful groupthink. How about being open to learning other tools? Locking yourself into a single ecosystem and bothering otherwise productive people who don't buy into it is how we get SourceForge.
- IshKebab 9y ago
  > is how we get SourceForge SouceForge was never a particularly good site, and once a better one came along everyone moved off it fairly easily. Seems like working as intended. If Github goes evil like SourceForge did I don't imagine it will be a huge amount of effort to move to another site. In fact it can probably be automated for most projects.
- frou_dh 9y ago
  For high stakes projects, I feel there's an aspect of "choose your battles wisely". Is relenting in some dimension going to harm the overall goal? IIRC Go was hassled off of mercurial and onto git, so there's a bit of a fractal too.
kingmanaz 9y ago
Suggestion: Follow the OpenBSD project's lead and end this debate with blanket adoption of CVS. Also, a "Comic Sans" website makeover would severely cut down on the golang community's hipster ratio.
mikekchar 9y ago
Possibly off topic, but this prompted me to take a long overdue re-peek at git-appraise (distributed code review tool, written by google in go). I notice there is now a git-appraise-web. It looks pretty nice (exceptionally minimal :-) ), but their demo lacks any comments to see how it might work in collaborative form. Does anybody use git-appraise (and especially a web client) and have any comments?
jballanc 9y ago
> When Google keeps the canonical git repo in googlesource, and uses a google-run gerrit instance for code reviews, it does not make the project feel like it's open source. It makes it feel like it's a google project that they let the rest of us look at from afar, and participate in if we're willing to hike up the mountain. I hate to break it to ya', but I think this isn't just what it feels like. The sooner people realize that "Open Source" is different than "Open Development", the better. That said, I think it's a stretch to assume that Go is contributor hostile just because it hasn't gone all-in on GitHub. Just off the top of my head: Ruby, Python, Javascript, Lua, Clojure, C++, and Java are all languages that haven't embraced the "GitHub Workflow". Indeed, the only language I can think of that has is Julia. Actually, I just checked, and it looks like Rust is also bought in to the GitHub Workflow. So that makes it: 2 for, 7+ against.
- steveklabnik 9y ago
  Ruby historically has not wanted to move to GitHub because core prefers svn to git. That said, https://github.com/ruby/ruby/ https://github.com/ruby/ruby/ exists, and committers will (in my understanding) take PRs from it and merge them in, see https://github.com/ruby/ruby/pull/1661 https://github.com/ruby/ruby/pull/1661 for example. This has happened because the same kinds of discussions have come up with Ruby for years, especially since GitHub came out of the Ruby world, and the Ruby community overall has used GitHub longer and more than most as a result. There are things that we in Rust find annoying about GitHub, but they're mostly addressed through things like bots; there's no significant push by anyone to move away from GitHub.

68 points by ahacker15 9y ago

I wonder if Google really loves Gerrit, or if it’s just a legacy NIH attachment and some of Google’s graybeards just refuse to let it go. Having worked with Gerrit in the past, I can say without a shadow of a doubt, it’s an abomination and I’d lop off a limb rather than voluntarily use Gerrit again.

dannyw 9y ago
Do you really think Google can really put their whole development and review infrastructure into the hands of a relatively small company named GitHub? The same platform where you see "GitHub is down" on HN every couple of months?
- hellofunk 9y ago
  Well, Apple has done a lot of it with Swift. Language evolution discussions and the code itself is on GH.
- coldtea 9y ago
  >The same platform where you see "GitHub is down" on HN every couple of months? Because Google's internal and external services don't go down? Ever tried GAE?

gksmythe 9y ago

The tyranny of GitHub. GitHub pull requests are one of the most cumbersome ways of contributing to OSS. What people really like is: a) The paper trail (I can show to my career manager that I've done some work). b) The constant distractions that feel like work. c) Minor issues seem like major contributions. d) Self promotion.

matt4077 9y ago
This is insane, considering the process before github was "send a patch by email". Hundreds of thousands of people, including me, have started contributing patches because the Github process has a much lower barrier to entry, is standardised, and effortlessly teaches you how to do it when you browse around a project.

maaaats 9y ago

Kinda scary how de facto Github has become, that external tooling is discouraged. Github is a bad issue tracker, a bad code review tool, an ok wiki and a bad distribution platform. Still, one has to mostly use the whole package to get contributors. (Github has other strengths, though)

giancarlostoro 9y ago
BitBucket is plenty popular as well, I run into projects that are on there instead of GH for Python. I kind of prefer BitBucket to GitHub the only thing GitHub does right is their "Explore" section which I don't think BitBucket has (or GitLab?) but that's about it for me. I don't care where one hosts code, as long as it's not some obscure server.
- matwood 9y ago
  For a long time BitBucket was the only one with the protected branch feature that could prevent history rewrites on a branch by branch basis. Github finally added it after the force push that blew away so many critical repositories. BitBucket also has free private repos. I only use GH for projects that are open source because that's where people expect OSS to be.
  - StavrosK 9y ago
    I use Gitlab and just have it push to Github, then disable issues/wiki/whatever else I can there, and add a link to the Gitlab repo in the description.
- hellofunk 9y ago
  GitHub has always had far superior code search features. BitBucket is gradually trying to add these, but they still pale compared to GitHub. I love just going through a repo by searching for things.
  - giancarlostoro 9y ago
    Except for when you want to search within a different branch.

shadowmint 9y ago

Unfortunately the epic comment thread, very talky, none of the key stack holders involved, largely irrelevant chatter... Is a case in point of why github isn't the answer for everything.

Tade0 9y ago
Wow, a proper use of the word "epic". I thought the original meaning was gone.
- coldtea 9y ago
  I doubt the GitHub thread was "a long poem, typically one derived from ancient oral tradition, narrating the deeds and adventures of heroic or legendary figures or the past history of a nation"
  - Tade0 9y ago
    You're confusing a noun with an adjective. As an adjective it's something that's "extending beyond the usual or ordinary especially in size or scope".
    - matt4077 9y ago
      The adjective is obviously. derived from the noun, and as such had much of the same meaning originally: "relating to or characteristic of an epic or epics: our national epic poem Beowulf." And no, I'm not proud of having to weigh in on this subject.
    - coldtea 9y ago
      epic, adjective 1. relating to or characteristic of an epic or epics. 2. heroic or grand in scale or character. "his epic journey around the world" You were saying?
      - Tade0 9y ago
        Citation needed. Here's my source: https://www.merriam-webster.com/dictionary/epic https://www.merriam-webster.com/dictionary/epic

dmitriid 9y ago

Ah, the joys of a distributed version control system: let's put all code on GitHub and depend on it for everything.

mbrock 9y ago
The joy of decentralization to my mind is not a total avoidance of centers, it is resilience against those centers becoming obnoxiously or harmfully authoritative. Because Git is already thoroughly decentralized in its architecture, I'm not particularly afraid of GitHub, though I rely on it daily. I know that I can migrate from it without any fundamental problems. Development workflows are decoupled from their servers in a robust way. Commit hashes and GPG signatures mean that GitHub is not really a trusted central point, but a useful hub. Issue tracking is centralized on GitHub, and that's the biggest problem with it. Maybe that's a lock-in strategy from GitHub the corporation, although the APIs do allow migration.
frou_dh 9y ago
Well it can be a pure win. As long as GitHub is used as a "dumb" git host that's just another node in the network. As you mentioned, the dubious part is if it captures control of all of your "meta" processes too.

nascent10 9y ago

The proposal comments are a wave of silly millennial entitlement. GitHub has ruined software development for adults.

rectang 9y ago

In my experience, there are no debates so fraught and vicious as those over version control platforms. Questions of more open governance for Go really ought to be separated from Github specifically. Moving from googlesource to Gitlab or Bitbucket would achieve the same thing. Which is actually not much: just because a project is on a given commercial hosting platform doesn't portend a change in how decisions get made over project direction, as many projects hosted on Github (and Gitlab and Bitbucket) illustrate.

deleted 9y ago

[deleted]

dis-sys 9y ago

the proposal is cute and funny, basically the author argues that to make the contribution and governance process more open, everything has to be done on github to be more closely aligned with what project X,Y,Z are doing. that is not open or free, that is the exact opposite of being free and open.

coldtea 9y ago
Open as in actually welcoming and convenient for people to participate. Not in the religious/GNU sense.

alenmilk 9y ago

From the comments on the page: jimmyfrasche commented The language spec is easier to read than the contribution guidelines

arkadiytehgraet 9y ago

If one cannot figure out how to setup a development environment (with detailed guides), how can one be expected to actually make a meaningful contribution in a much more difficult domain like compiler development? For this purpose alone I think the current approach is something that Google will not get rid of. Moreover, why on Earth would Google want to create an external dependency for code-hosting and development like GitHub, that may go down anytime, making them lose a lot of time and money, especially since their own system is much more reliable (at least for internal usage) and they have all resources they need to maintain it? Finally, it is somewhat really silly to think that a giant corp like Google will develop something truly free and opensource, without their own interests above anything else, which obviously will become an issue sooner or later with the truly freedom spirit.

_asummers 9y ago
The article addresses how Google is already using GitHub with Kubernetes. Looks like Dart does too from glancing through the GitHub. If you're worried about external services going down, you make an internal mirror. You don't force the whole workflow to go through your system.
- arkadiytehgraet 9y ago
  Or you just don't use an external service in the first place, minimizing your dependencies, which you arguably should be doing anyway? They are not forcing anyone to go through their system, it is completely your choice to either help the project or not.
lloeki 9y ago
> If one cannot figure out how to setup a development environment (with detailed guides), how can one be expected to actually make a meaningful contribution in a much more difficult domain like compiler development? Because those are two unrelated fields, and one is distinctly not productive. From the issue: > I ran through the contributing workshop at Gophercon 2017. I even had gone through half of it before. I still needed help from one of the guides. It was still arduous. I speak as someone who has written Go professionally 40 hours a week for over 4 years - the contribution workflow deters me from contributing to the Go project. Even after signing up. The fact that it's so different from my everyday workflow just makes the hill to climb too steep. And comments (from current contributors no less): > I've been writing Go for over five years and contributing in various forms, and I have to say I agree. go-contrib-init makes things better, but the barrier to contributing to Go is a lot higher and with a different workflow from almost any other project that uses Go. > As successful as the contributor workshop at Gophercon was, it is an embarrassment to the language that we had to do it at all. Why did we need an entire seminar to teach hundreds of developers who already contribute to many other open source projects how to contribute to Go? Also, not every contribution to Go involves mucking with the compiler. > why on Earth would Google want to create an external dependency for code-hosting and development like GitHub Didn't they move to Google Code to GitHub, which is the live repo, Gerrit being used for code review only? If so, the dependency is already there. If not, why is it on GitHub at all? > Finally, it is somewhat really silly to think that a giant corp like Google will develop something truly free and opensource, without their own interests above anything else, which obviously will become an issue sooner or later with the truly freedom spirit. I think somehow this is tackled by the issue author, and is a canary of sorts: > Let's show the OSS world that Go really is a community-run project

hellofunk 9y ago

If one wants to see the merits or at least the experiences of a major language from a commercial entity going open source on GitHub, where all discussions, language features, issues, and code itself is in that one place, take a look at Apple's Swift. Edit: Looks like Swift doesn't use GH for issues any more.

andrewnez 9y ago
Swift switched all their issue tracking to Jira a while back
Androider 9y ago
Swift doesn't seem to be using GitHub's issue tracker, wikis or anything except the code hosting really.
- hellofunk 9y ago
  Well they use code files for discussions, so it's a bit different.

speps 9y ago

I've contributed a small patch to Go not that long ago and it was quite straightforward, I don't get why it has to be changed. Plenty of people have used the current workflow for years now...

hamax 9y ago

It's true that Gerrit's workflow is a bit unusual, but even though I had no experience with it, I managed to setup the environment and create a review request for Golang in under an hour. When it comes to contributing to a programming language, I think this is pretty friction-less. CLA was very painless too.

IshKebab 9y ago
An hour is pretty bad don't you think? Pretty sure it would be quicker with github.
- hamax 9y ago
  Sure it would be. Mostly because I use Github every day. The first time I tried to create a pull request it probably took me almost as much time to figure out how Github works. But compared how much time is saved for reviewers by having a better tool, I think 1 hour for each new contributor is reasonable.

TurboHaskal 9y ago

Hi PCJ!

Sir_Cmpwn 9y ago

The "just use GitHub" mentality is harmful groupthink. How about being open to learning other tools? Locking yourself into a single ecosystem and bothering otherwise productive people who don't buy into it is how we get SourceForge.

IshKebab 9y ago
> is how we get SourceForge SouceForge was never a particularly good site, and once a better one came along everyone moved off it fairly easily. Seems like working as intended. If Github goes evil like SourceForge did I don't imagine it will be a huge amount of effort to move to another site. In fact it can probably be automated for most projects.
frou_dh 9y ago
For high stakes projects, I feel there's an aspect of "choose your battles wisely". Is relenting in some dimension going to harm the overall goal? IIRC Go was hassled off of mercurial and onto git, so there's a bit of a fractal too.

kingmanaz 9y ago

Suggestion: Follow the OpenBSD project's lead and end this debate with blanket adoption of CVS. Also, a "Comic Sans" website makeover would severely cut down on the golang community's hipster ratio.

mikekchar 9y ago

Possibly off topic, but this prompted me to take a long overdue re-peek at git-appraise (distributed code review tool, written by google in go). I notice there is now a git-appraise-web. It looks pretty nice (exceptionally minimal :-) ), but their demo lacks any comments to see how it might work in collaborative form. Does anybody use git-appraise (and especially a web client) and have any comments?

jballanc 9y ago

> When Google keeps the canonical git repo in googlesource, and uses a google-run gerrit instance for code reviews, it does not make the project feel like it's open source. It makes it feel like it's a google project that they let the rest of us look at from afar, and participate in if we're willing to hike up the mountain. I hate to break it to ya', but I think this isn't just what it feels like. The sooner people realize that "Open Source" is different than "Open Development", the better. That said, I think it's a stretch to assume that Go is contributor hostile just because it hasn't gone all-in on GitHub. Just off the top of my head: Ruby, Python, Javascript, Lua, Clojure, C++, and Java are all languages that haven't embraced the "GitHub Workflow". Indeed, the only language I can think of that has is Julia. Actually, I just checked, and it looks like Rust is also bought in to the GitHub Workflow. So that makes it: 2 for, 7+ against.

steveklabnik 9y ago
Ruby historically has not wanted to move to GitHub because core prefers svn to git. That said, https://github.com/ruby/ruby/ https://github.com/ruby/ruby/ exists, and committers will (in my understanding) take PRs from it and merge them in, see https://github.com/ruby/ruby/pull/1661 https://github.com/ruby/ruby/pull/1661 for example. This has happened because the same kinds of discussions have come up with Ruby for years, especially since GitHub came out of the Ruby world, and the Ruby community overall has used GitHub longer and more than most as a result. There are things that we in Rust find annoying about GitHub, but they're mostly addressed through things like bots; there's no significant push by anyone to move away from GitHub.