
Golang Proposal: Just Use GitHub - ahacker15
https://github.com/golang/go/issues/21956
======
maaaats
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
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
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
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.

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

~~~
lloeki
_> 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_

~~~
Sir_Cmpwn
>Because those are two unrelated fields, and one is distinctly not productive.

Each of your examples is something like "I've been writing go for x years".
Using a programming langauge does not make you a compiler hacker. Countless
people have been using Linux for years but wouldn't be able to make a
meaningful contribution to the kernel.

I'm firmly convinced that having to learn something as straightforward and
well documented as golang's contributor flow is a pretty good litmus test for
potential contributors.

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

Git repositories are distributed. It doesn't really matter where the upstream
is, that has little bearing on project governance.

~~~
coldtea
> _Each of your examples is something like "I've been writing go for x years".
> Using a programming langauge does not make you a compiler hacker._

Becoming an expert on whatever custom commit process a project has does even
less to make you a compiler hacker.

~~~
Sir_Cmpwn
Correct, but the inverse is typically true - not being willing to learn
anything but GitHub is a pretty good indicator for not being able to hack on
compilers.

~~~
marssaxman
I am able to hack on compilers and have spent much of my career doing so. I am
also able to learn new development workflows involving idiosyncratic tools
which must be installed and configured; I've done it over and over, at many
different jobs. You know what? It's a lot of work, and it's all basically a
waste of time. I'll do it if I'm paid to, but I'm not interested in spending
my free time that way.

------
shadowmint
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
Wow, a proper use of the word "epic".

I thought the original meaning was gone.

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

~~~
coldtea
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
Citation needed.

Here's my source: [https://www.merriam-
webster.com/dictionary/epic](https://www.merriam-webster.com/dictionary/epic)

~~~
coldtea
Mine was OS X dictionary IIRC, but here's dictionary.com:

adjective, Also, epical 1\. noting or pertaining to a long poetic composition,
usually centered upon a hero, in which a series of great achievements or
events is narrated in elevated style: Homer'sIliad is an epic poem. 2\.
resembling or suggesting such poetry: an epic novel on the founding of the
country. 3\. heroic; majestic; impressively great: the epic events of the war.
4\. of unusually great size or extent: a crime wave of epic proportions. 5\.
Slang. spectacular; very impressive; awesome: Their burgers and fries are
epic!

So if (4) is what you mean, it's not exactly the first definition for the
adjective either.

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

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

------
hamax
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
An hour is pretty bad don't you think? Pretty sure it would be quicker with
github.

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

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

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

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

------
mikekchar
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?

------
alenmilk
From the comments on the page:

jimmyfrasche commented

The language spec is easier to read than the contribution guidelines

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

------
dis-sys
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
Open as in actually welcoming and convenient for people to participate.

Not in the religious/GNU sense.

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

~~~
Androider
Swift doesn't seem to be using GitHub's issue tracker, wikis or anything
except the code hosting really.

~~~
hellofunk
Well they use code files for discussions, so it's a bit different.

------
grabcocque
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
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?

~~~
coldtea
> _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?

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

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

------
TurboHaskal
Hi PCJ!

