New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Just Use Github #21956

Closed
natefinch opened this Issue Sep 21, 2017 · 150 comments

Comments

Projects
None yet
@natefinch
Contributor

natefinch commented Sep 21, 2017

Before I begin, let me say that I believe that Google and the go team (whatever we may mean by that term) really want Go to be a true open source, community project. My comments herein are intended to shine light on how the current state of Go's development process belies this fact.

There are two common complaints when it comes to the development of Go itself:

  1. It's too hard to contribute (this was a whole section of Steve Francia's talk at Golang UK)
  2. Go feels like it's a Google-owned-and-controlled project that is not truly "open source"

Both of these are exasperated by the fact that the technical workflow that the Go project uses is significantly different than what has become standard" for much of the open source community. The standard being - use Github. Use GitHub as the primary code storage, use GitHub for issues, use GitHub for PRs, use GitHub for reviews. The reasons for this are twofold - one, they are integrated and closely localized. Two, they're what everyone is already using, so there's zero cognitive overhead. I think most of us can create a PR in our sleep.

#18517 talks about accepting PRs... .except that it's not really accepting PRs. It's using PRs as a way to feed code into gerrit. This is going to be a terrible user experience, because it will be disconnected from the normal github workflow. Whatever features Gerrit has over GitHub obviously cannot be translated correctly to github, so the bridge necessarily must be lossy. People will expect to be able to receive comments in a different tab of the same page of their PR... but they will instead have to go to a completely different, disconnected UI on a different domain.

Not only is this a bad user experience, it is yet another signal to potential contributors that they aren't really that welcome. After all, tens of millions of developers use GitHub every day. Projects bigger than Go use GitHub a their main development process in all ways.

Things like The Go project contributing flow is currently configured to work only with Google Accounts. and Our canonical Git repository is located at https://go.googlesource.com/go send not-so-subtle signals that this is a Google project, not really a community project.

The first two lines of the contributing guide are The Go project welcomes all contributors. The process of contributing to the Go project may be different than many projects you are used to.

If the first is true, the second should not be true.

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.

Other large open source projects seem to do just fine. Look at Kubernetes. It's only 3 years old. And it already has almost 50% more contributors than the language it's written in. It uses GitHub for code reviews, issues, PRs, etc.

In my personal experience, the Juju team at Canonical was approximately 25 full time developers when we switched from using ReviewBoard (which has many of the same features as Gerrit) to GitHub reviews. It was much nicer to have the reviews available in the same page as the PR itself. It was nice that the workflow was the same we used for our side projects. It was nice that contributors didn't have to learn new tools and create new logins on external sites. It was nice not to have to maintain those external systems.

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.

Let's show the OSS world that Go really is a community-run project. Let's make GitHub the first class citizen that it ought to be in the development workflow for Go. Let's drop the barrier of entry that currently exists even for experienced developers, so that contributing to Go only requires a few clicks through an automated CLA signing process and then normal PRs, reviews, normal git tooling.

@gopherbot gopherbot added this to the Proposal milestone Sep 21, 2017

@gopherbot gopherbot added the Proposal label Sep 21, 2017

@ddatsh

This comment has been minimized.

ddatsh commented Sep 21, 2017

too hard to contribute, can't agree anymore!

@marwan-at-work

This comment has been minimized.

Contributor

marwan-at-work commented Sep 21, 2017

I've heard on the Gotime podcast and Q&As with the Go Team that Gerrit provides a better experience when it comes to reviewing pull requests.

My question is, what makes a strong argument for Gerrit that Github cannot provide?

@ChimeraCoder

This comment has been minimized.

Contributor

ChimeraCoder commented Sep 21, 2017

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.

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.

Gerrit does provide a better experience for code review than Github does, though that difference has shrunk over time. At the time Go migrated to Github from Google Code, Github didn't even support split views for diffs! Gerrit still supports a number of things that Github doesn't, but the difference has narrowed significantly. And in my opinion, the opportunity to have more contributors and contributions is enough of a benefit to outweigh the product advantages that Gerrit has when viewed in isolation.

@kris-nova

This comment has been minimized.

kris-nova commented Sep 21, 2017

I couldn't agree with this enough, one of the things I hear most in the wild is how hard it is for people to contribute to 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? I think the avenue in which we interact with the Go source code is hands down the culprit.

If we need concrete data in the guise of experience reports I am happy to provide it.. But honestly I think this issue is probably going to turn out as enough.

@FiloSottile

This comment has been minimized.

Member

FiloSottile commented Sep 21, 2017

I agree that GitHub is closing the feature gap, but Gerrit reviews are still a different experience, which I personally find superior. So I think this should configure as a discussion on the tradeoff between review experience and new contributor experience.

But there seem to be two other sentiments in the proposal which I feel like are unrelated and personally disagree with.

First, that GitHub is "the one true way". I don't take seriously the complaints at the other end of the spectrum like "git was supposed to be decentralized!!!11!" either, but "it's not GitHub" should not be an argument against a workflow per-se, beyond the onboarding inertia, nor does all code need to be hosted on GitHub.

Second, the Google ownership part. Technical infrastructure is IMHO both much less important than people (which the Go team seems to be aware of and working on) and wider than Gerrit. TryBots run on Google infra, releases run on Google infra, the website runs on Google infra. And personally I'm glad the community doesn't have to piece it together.

@Carpetsmoker

This comment has been minimized.

Carpetsmoker commented Sep 21, 2017

Back when I hosted my code on BitBucket and mercurial I noticed that people would download my hg repo, make their changes, and then upload it to GitHub, and never sent me a patch.

Obviously not great. So, I moved everything to GitHub. Not because I especially like GitHub, but because git and GitHub have become the de-facto idiomatic tools for open source software development.

I still consider mercurial/BitBucket to be superior – but GitHub is certainly an adequate solution, and using idiomatic solutions is an advantage in and of itself. In that sense it's similar to the Go proverb of "gofmt GitHub is no one's favourite, yet gofmt GitHub is everyone's favourite".

I would say that the question "is Gerrit better than GitHub reviews?" is the wrong one. The question should be "is Gerrit so much better that we want to skip out potential contributions?"

I don't have to work with these tools daily, so I don't presume to be able to answer that question. We work with GitHub reviews daily at my day job, and while it's certainly not the best system I've worked with, I do find it an adequate system.

@ericlagergren

This comment has been minimized.

Contributor

ericlagergren commented Sep 21, 2017

We disagreed a bit on Twitter, but I do share your sentiments.

Switching to GitHub means GH is the sole source of truth for Go. This means if anything happens to GitHub—outages, data loss, whatever—or if GH does anything to its product—API limits, changes that break Go's workflow, etc—Go is out of luck. The Go project can avoid those problems if it uses an OSS tool, like Gerrit or GitLab.

Like I mentioned on Twitter, I wonder if the onboarding process could be made smoother if the docs received some TLC. (That doesn't speak to the part of your issue about Google's ownership, however.)

@tylerb

This comment has been minimized.

Contributor

tylerb commented Sep 21, 2017

Agreed. I'd be much more inclined to contribute if not for the contribution process.

One of my previous contributions was closed due to inactivity. I submitted it ages and ages ago, and had no idea it had been reviewed or commented on. After a long time, it was closed cause I didn't respond.

I happily would have responded and finished out the change had I received notification that it had been reviewed. No idea why I didn't get an email or some kind of notification, but I simply threw up my hands at that point. Not worth the rigamarole.

@natefinch

This comment has been minimized.

Contributor

natefinch commented Sep 21, 2017

I don't really think it's worth worry about "what happens if GitHub does X". If that happens, Go can move somewhere else (presuming there's off-GitHub backups, which I didn't even bother to mention because of course there would be). But in reality, github's not going anywhere, and they're not going to do anything to screw up the hen that lays the golden egg.

You might as well say "what if Google goes under?" I mean... they actually have closed down one of their source control hosting services :)

@jimmyfrasche

This comment has been minimized.

Member

jimmyfrasche commented Sep 21, 2017

The language spec is easier to read than the contribution guidelines

@NuckChorris

This comment has been minimized.

NuckChorris commented Sep 21, 2017

@natefinch I'm not sure if there are tools to backup github issues, but if there aren't, that's yet another reason to switch wholeheartedly to github: the same things which make github better for the Go team will make it better for everybody.

@nasciiboy

This comment has been minimized.

nasciiboy commented Sep 21, 2017

bravo! I wanted to help add support for negative numbers in text/scanner and see the collaboration guide does not invite me to do it

registering a google account on a mandatory way, or accepting a contract to cede code to a project that is already OSS, sucks.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 21, 2017

As a person who reviews patches, it seems to me that Gerrit continues to provide a much better mechanism for patch review than Github. Even with our current contribution process, there are many many more contributors than there are reviewers.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 21, 2017

@nasciiboy Whether we use Gerrit or Github, all contributors will be required to sign the CLA to give us rights to distribute the contributed code. That is non-negotiable.

@natefinch

This comment has been minimized.

Contributor

natefinch commented Sep 21, 2017

Yeah, I wasn't assuming the CLA would go away, but hopefully it could be a trivial click through process that could use your GitHub id so you don't have to sign up for anything.

@as

This comment has been minimized.

Contributor

as commented Sep 21, 2017

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.

I agree completely with this, but at the same time it doesn't feel right to expect the top contributors to tailor the workflow for the rest of the potential contributors. It seems important, at least to me from a quality standpoint, that those who review the most code have the easiest time doing it, as they are the gatekeepers of quality.

I'm not saying it should be harder to contribute to keep contributions away, just that the write-access (or pull access) should not be optimized at the expense of read access (code review, ease of use, etc).

@agnivade

This comment has been minimized.

Member

agnivade commented Sep 21, 2017

I myself had kept away from contributing due to this very reason for a very long time. Recently though, I just sat down and forced myself to go through the contributor doc. Hardly took me 15 mins, and then I was up and running ! And this was even before go-contrib-init came out !

Yes, the gerrit workflow is something new, and like anything new, people (including me !) are reluctant to put themselves through the time and energy of learning that. But IMHO, its too small of a learning curve to complain about.

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

And like @FiloSottile said, the TryBots do run on Google hardware. If we are talking about moving away from Google completely, I doubt one can run tests on all platforms and with the speed the current TryBots do.

@slrz

This comment has been minimized.

slrz commented Sep 21, 2017

Not relying exclusively on Github doesn't make a project any less community-driven. It simply does not compute.

You make it sound as if Go was some kind of weird outlier when in fact it is very common for bigger open source projects to use Github mostly as a fancy mirror while the primary repo and code review live somewere else.

@purpleidea

This comment has been minimized.

purpleidea commented Sep 21, 2017

Just drop the CLA entirely. This is corporate nonsense used to make the lawyers feel happy and benefits none of the hackers. Everyone knows that inbound=outbound. #NoCLA

@rakyll

This comment has been minimized.

Member

rakyll commented Sep 21, 2017

I'd love to see GitHub doing some improvements to the comment handling. There is currently no way of drafting replies when replying to a code review, or there is no mechanism that counts the addressed and non-addressed issues. It is a major step down if you are reviewing long and complicated patches, the way the Go project often does.

@natefinch

This comment has been minimized.

Contributor

natefinch commented Sep 21, 2017

@cespare

This comment has been minimized.

Contributor

cespare commented Sep 21, 2017

@rakyll GitHub fleshed out their review system quite a bit in the past 6 months - 1 year. Pull Request Reviews work such that you can write a bunch of comments as drafts (and edit/delete them) and then send the review as a single batch, like Gerrit. See this and this, for example.

@jimmyfrasche

This comment has been minimized.

Member

jimmyfrasche commented Sep 21, 2017

I don't care about the CLA or where the main repo is. It's just too hard to contribute.

Gerrit might be nice if you use it all day or even once a month, but, if you look at it maybe once a year, it's a mess.

The rest of it isn't that bad, though the contribution guidelines are hard to skim. It's not bad if you actually read it but if you just open it up with the goal of "to do X I need to do Y", well, buckle in. By the time I figure out what to do I've lost any steam I had to actually do it. Eventually after many months, I'll try again but by then I've forgotten what to do and the cycle repeats.

@rakyll

This comment has been minimized.

Member

rakyll commented Sep 21, 2017

@cespare You can only create an initial draft. Responses to the initial comments cannot be drafted. Am I mistaken? I use GitHub PRs for everything else and it is such a chaotic experience even for tiny projects.

@cznic

This comment has been minimized.

Contributor

cznic commented Sep 21, 2017

This proposal is based on things that I disagree with almost entirely. Moreover, some of them are IMO false.

Several people agreed to the claim that's it's hard to contribute. Yeah, you may have to learn a couple of new things. Maybe you make some mistakes in the first case. Trial and error, less than 30 minutes, I guess, and basically only once and forever. We are programmers, we are used to learn new things every single day of our profesional life - or we are soon out of business. (Good luck to the exceptions.)

TL;DR: I see very little technical ground justifiyng the proposal. Only same strange mix of activism and/or policy making. I am very much against.

@cespare

This comment has been minimized.

Contributor

cespare commented Sep 21, 2017

@rakyll Yes, I think you're mistaken. You can respond to a PR review by doing your own review which works the same way (except that you can't approve/disapprove your own PR). You do this by responding to a comment with "Start a review" rather than "Add single comment". I think this is only available on the "Files changed" tab, not the "Conversation" tab (not sure why). See pic:

screen_20170920223353

@mattn

This comment has been minimized.

Member

mattn commented Sep 21, 2017

I don't have strong opinion.

Go developer team have to manage issues or pull-requests which is not really issue. For example, complaints, dissatisfaction, biased benchmark results. If PR will be opened, meaning-less PR possibly be sent. I have seen a pull-request where all sources are deleted in other project. Ofcourse, we doesn't want it.

Also since we can do anything on GitHub with only few clicks, there are possibly mistakes that will occur. This can be recovered but it should be carefully. For example, the counting of LGTMs like Gerrit (maybe rakyll mentioned).

I think that using Gerrit still have meaning since gerrit have better way for reviewing. In other thing, I am not a Google believer, but I think, Not to use GitHub may be possible way to raise the contributor's threshold. (Please do not treat this as wrong) This can ignore users who doesn't have development intention that mentioned above.

IMO, I don't think it's not hard to contribute to Go as you think.

@andybons

This comment has been minimized.

Member

andybons commented Sep 21, 2017

This proposal is rather large in scope and the discussion could be more productive if broken out into more specific bits to avoid derailment (talking about the CLA, for example). The primary (and most contentious) issue seems to be that of moving away from Gerrit to use GitHub PRs for code review. I suggest you make this proposal more specific to that issue, because it's the one that a lot of your other sub-proposals hinge on.

I 100% agree that it is more difficult to propose a change to Go than to say, Kubernetes. This experience is something we're trying to improve on and the contributor workshop at GopherCon was a great demonstration of the roadblocks some of our community members run into by using Gerrit and our current tooling. We should do better.

While switching to GitHub would potentially make a contributor's workflow more straightforward, the same cannot be said indefinitely for the reviewers. Switching to GitHub PRs would regress the review experience for many, so the success of this proposal hinges on identifying those regressions and either convincing the maintainers that the corresponding benefits outweigh the sacrifices, and/or coming up with a plan to build tooling to fill in the gaps left by switching.

@jimmyfrasche

This comment has been minimized.

Member

jimmyfrasche commented Sep 22, 2017

I've filed #21983 for a possible way to improve the contribution guidelines in the meantime based on issues I've had with my aborted attempts at the process

@rsc

This comment has been minimized.

Contributor

rsc commented Sep 22, 2017

FWIW, @dlsniper, yes, that has come up in the past: https://twitter.com/bradfitz/status/692510984339111936. :-)

@mxplusb

This comment has been minimized.

mxplusb commented Sep 22, 2017

I wanted to chime in here, not because I necessarily have something to add, but to add an interesting perspective and experience from two contributors.

I used to frequent the Gophers Slack channel, so I could help people ad hoc. I met @zmb3 because he had asked for help with the “git-code-review” tool after it put him in a weird state. After working with @zmb3 for awhile to get him unstuck, he got me an interview with his company and ultimately I got a job.

My point is the process is so poor/complicated/convoluted/, less so now, for contributors, being able to help someone get unstuck got me a job because it’s a black magic process. I have made a couple small contributions in my several years of professional Go experience, and I decided I didn’t want to keep contributing because the process was complicated.

I get that cherry-picking is super helpful, but as half the Golang build infrastructure does various git operations anyways, a merge workflow with cherry-picking would be easy to add.

@forskning

This comment has been minimized.

forskning commented Sep 22, 2017

https://gerrit.googlesource.com/summit/2017/+/master/index.md

Gerrit User Summit 2017
30 Sept. through 3 Oct.

CodeNode, 10 South Place,
London, EC2M 7EB, GB

@golang golang deleted a comment from soccerJoshNumberNine Sep 22, 2017

@forskning

This comment has been minimized.

forskning commented Sep 23, 2017

http://www.varastokirjasto.fi/digiphpt/dump_fnatur.txt
"28 Skogen och vår identitet Erkki Lähde";;"1984"

'The Forest and our Identity'

Prof. Lähde recounts when as a young graduate out of forestry studies, he had the occasion to visit a village in the Finnish countryside. He noticed in the area a group of trees which to his view was overdue to be cut. But enquiring upon the local villagers of that stand of trees, the reply was that there was an old woman from the village who had liked to walk among that grove. Thus the trees were saved out of piety.

Erik Erikson, a Norwegian pædagog had introduced me to his writings, wrote once of how moralistic man and rationalizing man, as an emotional and political being undoes with "compulsions and impulses what his thought has invented and what his hands have built".

There's also a Viennese saying:

"Es pressiert nicht. Wir haben Zeit."

So, a valid question for me:

Is there an æsthetic in the workflow of those using Gerrit?

@ghost

This comment has been minimized.

ghost commented Sep 23, 2017

It is important to understand the level of effort it takes for maintainers to review so many changes. Github does not make that easy for projects with a high volume of "pull requests". Gerrit helps maintainers tune in and accept changes. Github is just a UI!

@ghost

This comment has been minimized.

ghost commented Sep 23, 2017

Each commit should be laser-focused on a particular issue and include Release Notes suitable for user consumption. There is no excuse for sloppy, mangled pushes.

@EddieRingle

This comment has been minimized.

EddieRingle commented Sep 23, 2017

I read through this thread, and I find it interesting that the other of the two complaints brought up in the OP is the one I feel is the legitimate issue, yet it got practically no attention:

Go feels like it's a Google-owned-and-controlled project that is not truly "open source"

But before I get to that, I will briefly comment with regard to GitHub vs Gerrit and "ease of contributing". If Gerrit is complicated or unfamiliar, then it seems the most productive plan of action is to report issues to the Gerrit project or even contribute improvements directly. You're much more likely to effect change in Gerrit (or a similar open source tool) than others will have in convincing GitHub to add the various features it lacks for reviews, among other things.

Additionally, if the Go team were up for changing the system, I would personally push for using git format-patch/send-email, which is used by the Linux kernel as well as countless other long-running open source projects (or if they don't use Git, they still use a mailing list system). I'd propose it mainly because, aside from those commands being included in Git and the workflow arguably being even easier than Gerrit (it's just email!), it would still offer some semblance of the functionality Gerrit offers, but it would also create a little mayhem, too--and who doesn't enjoy that every now and then? :)

Now, back to that second point. Go is a "Google-owned-and-controlled project". That CLA you sign? It assigns the copyright grants a license for your contributions to Google. I'm not about to claim that the CLA is much of an issue, though. Go can be Google-owned and still be an open source project. There are other symptoms that could be looked at instead, in my opinion.

Quite a few times I've either read or taken part in discussions that included one of the Go team members mentioning a topic as having been discussed by the Go team in one of their internal meetings, sometimes not expanding beyond that. Similarly, I feel like the team's resistance to shortening the 6-month release cycles to approach a more continuous-delivery-style pipeline might be evidence that the team is sort of siloed by Google's internal mechanisms and culture. If you're going to make the argument that Go doesn't feel like a true "open-source" project, these would be some of the things I would want to discuss.

@FiloSottile

This comment has been minimized.

Member

FiloSottile commented Sep 23, 2017

I do not like where this thread is going.

An increasing number of comments are stating or implying that contributors not willing to put in the effort to overcome the inertia are somehow worth less. @Manishearth articulated well why it's wrong in #21956 (comment), but I want to go a step further and say that it's unacceptable.

While I fall on the side of optimizing for review myself, that's about process and resources, not people, and any lost contributor is an unfortunate trade-off which we should try to compensate for (which as @rsc reiterated is the point of #18517). Can't believe this had to be said.

(In case this sounded official, this is a personal opinion and I have no affiliations.)

@Manishearth

This comment has been minimized.

Contributor

Manishearth commented Sep 23, 2017

(it's just email!)

It's not. Lots of folks don't realize this, but git-send-email is a really hard workflow.

It works great if you already use a local mail client. Many don't. Many can't, because of port blocking and firewalls (a large fraction of universities do this for example). Port blocking SMTP in particular is annoyingly common because of the way spam detection works. If you are behind a large NAT (like a university, or a workplace), and you use the connection to send out lots of spam directly via SMTP, it's very easy for that IP address to get banned. The administrators may not want to deal with this, so they'll just block the port.

The traditional patch mailing list approach also has terrible UX even with git-send-email. Replying to a mail requires copying the message id and a bunch of nontrivial steps which are definitely not built in. It's possible to set up local mail clients to work well with this, but this is not the default behavior.

The obvious way out here is for folks to "just" use web based clients with git format-patch, but that doesn't work well either. For example, GMail converts tabs to spaces (or was it the reverse?) in plaintext emails, so you can't just paste git format-patch output there.

It's possible to build tooling that makes all this pleasant (I'd love for this to exist!), but it doesn't exist right now as far as I know. I would be wary of moving to a patch mailing list approach for reasons that it is simpler (it has its merits! this isn't one of them)

@willnorris

This comment has been minimized.

willnorris commented Sep 23, 2017

That CLA you sign? It assigns the copyright for your contributions to Google.

No, it's a copyright license, not a copyright assignment (read the full text). All contributors still retain full ownership of everything they contribute to this or any other Google open source project. This is orthogonal to the topics actually discussed in this issue, but I wanted to correct any misunderstanding on this point.

@EddieRingle

This comment has been minimized.

EddieRingle commented Sep 23, 2017

@willnorris - You're correct! Sorry, I got the terminology mixed up. It's late here. :)

@ghost

This comment has been minimized.

ghost commented Sep 23, 2017

OK, biased comment stricken. You've all got a good point. Maintainers also have to deal with all of this daily and some may be unpaid volunteers. In a perfect world Gerrit would have a GitHub integration plugin, IMO.

@davecheney

This comment has been minimized.

Contributor

davecheney commented Sep 23, 2017

A few months ago I was invited to join a panel on contributing to Go organised by Ashely McNamara.

During that panel I asked the audience, via a show of hands, "who felt that contributing to Go implies landing a commit on github.com/golang/go?".

Nobody raised their hands.

I mention this to suggest that contributing to Go is not limited to landing code in one specific repository. Aside from non code contributions like running workshops, meetups, user groups, conferences, and release parties, the majority of code written in Go (which is what I see as contributing to Go) will be in repositories outside github.com/golang/go (or its sister sub repositories), and this is how it should be.

Do people feel that they cannot contribute to Java because it is hard to submit a contribution to OpenJDK (which as I understand it has a highly cumbersome governance model)? Of course not; they contribute to products built on top of the JDK.

The notion that you are not a real or valued Go developer until you have contributed to the stdlib is toxic. This is the real problem.

@antonpaisov

This comment has been minimized.

antonpaisov commented Sep 23, 2017

self-hosted GitLab or gitlab.com is a better open choice IMO

@jchv

This comment has been minimized.

jchv commented Sep 23, 2017

I love GitLab, but GitLab.com is very unstable. Hosted GitLab CE would be cool, but I fail to see how that's not a lateral move. In my PoV, there's nothing wrong with Gerrit, there's just some potential gain for GitHub due to the sheer size of the open source community on GitHub.

@ColtonProvias

This comment has been minimized.

ColtonProvias commented Sep 24, 2017

For a project such as Go, the key issue barely discussed here is the sheer amount of infrastructure built on it. Docker, which is Go based, now runs infrastructure for major corporations and even countries. Much of Bitcoin, Kubernetes, CloudFlare, etc. heavily use Go. When a project serves as the base for that much, the process for making changes needs to be very nitpicky so as not to break major systems.

Linux is another open source project. It uses GitHub as a mirror, has a more complex contribution process, and is even more strict. It runs the majority of servers, so they need a very fine control over it.

Gerrit gives the reviewers more control and increases the efficiency. Yes, it may require more hoops than you may be used to. Yet Go is now mission critical to many just as Linux, Apache HTTPd, nginx, Docker, Python, MySQL are. At this point bugs and idiosyncrasies in the language are now features in active daily use. Making a small change could have an effect similar to pulling the left-pad package off of npm. Thus the process of contributing needs to be thorough, even if the extra testing and hoops seem redundant or unneeded.

@forskning

This comment has been minimized.

forskning commented Sep 24, 2017

@4ad

This comment has been minimized.

Member

4ad commented Sep 24, 2017

@Manishearth

(it's just email!)

[git-send-email] works great if you already use a local mail client.
Many don't. Many can't, because of port blocking and firewalls (a
large fraction of universities do this for example). Port blocking
SMTP in particular is annoyingly common because of the way spam
detection works. If you are behind a large NAT (like a university,
or a workplace), and you use the connection to send out lots of
spam directly via SMTP, it's very easy for that IP address to get
banned. The administrators may not want to deal with this, so they'll
just block the port.

This is not how git-send-email works. People DO NOT send
SMTP from their own machines. People using git-send-email USE
other SMTP servers just like people using any other mail client,
including Outlook or even Gmail on their phones. In fact, the
git-send-email literaly lists using Gmail for SMTP as an example.

@tcolgate

This comment has been minimized.

Contributor

tcolgate commented Sep 24, 2017

Github us not git, anymore that Sourcefirge was CVS or SVN. The idea that GitHub is the one true place to put code is ridiculous and short sighted.
The Gerrit flow is quite pleasant. I don't think there's any harm in exposing people to something a bit different.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 24, 2017

I think everyone has made their positions clear on this issue.

I think we have two plans: one is to tackle issue #18517 to add a flow between Github pull requests and Gerrit, and the other is to clearly document what seems to be lacking in the Github review flow as suggested in #21956 (comment) . I have created a new issue for the latter at #22002.

This issue is too large and diverse to usefully tackle either of those proposals, so I am going to close this issue. Thanks for everyone's input.

@Manishearth

This comment has been minimized.

Contributor

Manishearth commented Sep 24, 2017

People using git-send-email USE other SMTP servers just like people using any other mail client

@4ad which also goes through various ports (including 25) which are often blocked.

@dominikh

This comment has been minimized.

Member

dominikh commented Sep 24, 2017

Because port 25 isn't meant for client to MTA communication, port 587 is. And no respectable ISP blocks port 587.

@Manishearth

This comment has been minimized.

Contributor

Manishearth commented Sep 24, 2017

Many universities follow a whitelist, not a blacklist approach.

I've dealt with this problem with students I've mentored in open source more times than I can count.

(anyway, this is getting off topic)

@4ad

This comment has been minimized.

Member

4ad commented Sep 24, 2017

Many universities follow a whitelist, not a blacklist approach.

Literally every university in the world sends e-mail. Except perhaps universities from North Korea. If you can send e-mail, you can use git-send-email.

As this is both offtopic for this discussion, and also as this issue has been closed, I ask you to stop.

@wyattisimo

This comment has been minimized.

wyattisimo commented Sep 26, 2017

Both of these are exasperated by the fact that...

@natefinch exacerbated

@golang golang locked and limited conversation to collaborators Sep 26, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.