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

[lloeki]

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

It's just as much a litmus test of how much time you have in your hands to spend and space in your head to stuff peripheral stuff in. If you did not notice, there was a workshop about how to contribute to Go since, in contrast with its design and philosophy, it has a contribution method as convoluted as for Android/CyanogenMOD/LineageOS, which only makes the ridiculousness of it all the more poignant.

> Using a programming langauge does not make you a compiler hacker

Again, there is much more to Go than just the compiler, which is only a fraction of src. What if I want to contribute a substantial fix or improvement to say net/mail[0]? Or the documentation? Besides, how ludicrous is that a contributor wannabe should have to prove {him,her}self worthy of contributing by passing a supposed test entirely unrelated to the contribution {s,}he's intending to make?

Trivial fixes should be trivial to submit just as well as complex ones to review, and not require anyone to bang its head against an artificial wall.

[0]: https://golang.org/src/net/mail/message.go

[Sir_Cmpwn]

>It's just as much a litmus test of how much time you have in your hands to spend and space in your head to stuff peripheral stuff in.

If you don't have time to learn Gerrit (which is not a difficult tool to learn), then you probably don't have time to be a good contributor - responding to patch feedback, engaging in discussion, and maintaining your changes in the future should issues arise.

>there was a workshop about how to contribute to Go since

Just going to append my own conclusion to this sentence:

>since the entitled GitHub generation of programmers can't be arsed to spend 10 minutes learning any proper tooling

[4ad]

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

No.

Github is a mirror, the canonical git repository is at https://go.googlesource.com/go.

[arkadiytehgraet]

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

I beg to differ: they are both about solving problems; one set of problems (setting up development environment) is strictly easier in terms of cognitive load and actual technical ability than the other (compiler development). If you cannot solve problems from the first set, you simply cannot solve problems from the last.

>And comments (from current contributors no less):

Likewise, there are comments from different contributors, who claim that the current approach is better than GitHub:

>Agree with @ianlancetaylor that Gerrit does provide a better way to review patches.

>I've worked in some places where we've migrated from GH Pull Requests to Gerrit for the reason that GH Pull Requests (until very very recently) were not ideal for a formal review process. Even with the recent changes, the current PR system in GH does not manage revisions of a changeset well. For example, Gerrit includes the commit message as part of a review which is arguably the most important part of keeping a clean and detailed history.

Arguably, there are more people who are in favour of the Gerrit, rather than GitHub, even among those, who have tried both systems.

[matt4077]

> they are both about solving problems;

My car won't start. Shouldn't Google solve that first, before attempting to further improve search results? It's really easy to solve. (I lost the key)