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.<p>(Github has other strengths, though)
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.<p>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?<p>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.
Unfortunately the epic comment thread, very talky, none of the key stack holders involved, largely irrelevant chatter...<p>Is a case in point of why github isn't the answer for everything.
The tyranny of GitHub. GitHub pull requests are one of the most cumbersome ways of contributing to OSS.<p>What people really like is:<p>a) The paper trail (I can show to my career manager that I've done some work).<p>b) The constant distractions that feel like work.<p>c) Minor issues seem like major contributions.<p>d) Self promotion.
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.
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.<p>CLA was very painless too.
In my experience, there are no debates so fraught and vicious as those over version control platforms.<p>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.
> 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.<p>I hate to break it to ya', but I think this isn't just what it feels like.<p>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.
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...
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.<p>Does anybody use git-appraise (and especially a web client) and have any comments?
Suggestion: Follow the OpenBSD project's lead and end this debate with blanket adoption of CVS.<p>Also, a "Comic Sans" website makeover would severely cut down on the golang community's hipster ratio.
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.<p>that is not open or free, that is the exact opposite of being free and open.
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.<p>Edit: Looks like Swift doesn't use GH for issues any more.
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.<p>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.