Proposal: Just Use Github #21956
Comments
|
too hard to contribute, can't agree anymore! |
|
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? |
I've been writing Go for over five years and contributing in various forms, and I have to say I agree. 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. |
|
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. |
|
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. |
|
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 " 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. |
|
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.) |
|
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. |
|
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 :) |
|
The language spec is easier to read than the contribution guidelines |
|
@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. |
|
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. |
|
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. |
|
@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. |
|
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. |
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). |
|
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 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. |
|
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. |
|
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 |
|
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. |
|
Please drop talk about the CLA. If you want to propose that, make your own
proposal.
…On Thu, Sep 21, 2017, 1:03 AM James ***@***.***> wrote:
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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21956 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADCcyH3bMlx3OJHmGYlhzawuK2mS9yTLks5ske4RgaJpZM4Per9v>
.
|
|
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. |
|
@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. |
|
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. |
|
@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:
|
|
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. |
|
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. |
|
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 |
|
FWIW, @dlsniper, yes, that has come up in the past: https://twitter.com/bradfitz/status/692510984339111936. :-) |
|
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. |
|
https://gerrit.googlesource.com/summit/2017/+/master/index.md Gerrit User Summit 2017 CodeNode, 10 South Place, |
|
http://www.varastokirjasto.fi/digiphpt/dump_fnatur.txt '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? |
|
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! |
|
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. |
|
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:
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 Now, back to that second point. Go is a "Google-owned-and-controlled project". That CLA you sign? It 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. |
|
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.) |
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 The obvious way out here is for folks to "just" use web based clients with 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) |
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. |
|
@willnorris - You're correct! Sorry, I got the terminology mixed up. It's late here. :) |
|
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. |
|
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. |
|
self-hosted GitLab or gitlab.com is a better open choice IMO |
|
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. |
|
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. |
|
https://talks.godoc.org/github.com/go-hep/talks/2017/2017-08-24-go-hep-acat/talk.slide#1 A circa 2017 printing on Go and HEP. |
This is not how git-send-email works. People DO NOT send |
|
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. |
|
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. |
@4ad which also goes through various ports (including 25) which are often blocked. |
|
Because port 25 isn't meant for client to MTA communication, port 587 is. And no respectable ISP blocks port 587. |
|
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) |
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. |
@natefinch exacerbated |
and others
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:
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.andOur canonical Git repository is located at https://go.googlesource.com/gosend 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.
The text was updated successfully, but these errors were encountered: