Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Go

talks.golang.org

Post reply on HN
Print view View original

191–200 of 271 posts

Re: The State of Go

#191

Post by zak_mc_kracken »

dsymonds wrote: post #190
zak_mc_kracken wrote: post #185

> To create a patch one must fork the repository publicly (weird and unnecessary). I think it's very fair to demand from a contributor to sync and build the entire app before they're allowed to submit a patch. Interestingly, I note the Go team says it's "unnecessary" but doesn't provide their alternative.

We expect contributors to sync and run all the tests. The public forking is the weird and unnecessary part. Gerrit is the alternative used, and contributors have a full local clone of the git repo, with their commit, and that's private on their machine until they push it to Gerrit for review.

What is so disturbing about the "public" part that it's worth discarding the whole approach?

Re: The State of Go

#192

Post by zak_mc_kracken »

themightykevdog wrote: post #188
zak_mc_kracken wrote: post #178

Earlier quoted context omitted.

It's not exactly the first the time Go team is showing that they haven't spent much time researching current practices, theory, research and tools in the field of software engineering. Everything about the language screams of coming from minds who stopped learning new things in the late 90s.

This is so colossally misguided a comment it's hard to know where to begin. So I won't.

See my comment about "not wanting to learn".

Happy to engage in a discussion about modern software engineering.

Are you?

Re: The State of Go

#193

Post by MaulingMonkey »

yawaramin wrote: post #177
MaulingMonkey wrote: post #43

Earlier quoted context omitted.

> "In general, pull request culture is not about code review." > I have no idea what this means. Me either. To me, the entire point of pull requests is about triggering (code) reviews. If I don't want to bother with review, why not just grant direct push access and skip the rubber stamp ceremony?

Pull request culture is about enabling distributed collaboration, i.e. I don't have push permission to your repo and you don't have push permission to mine, but we can still collaborate by sending each other pull requests and sharing our work that way. It's all about collaboration while not trusting the other person with write access to your repo.

> It's all about collaboration while not trusting the other person with write access to your repo.

If I don't trust someone enough to grant write access to my repo, I certainly don't trust them enough to rubber stamp their pull requests.

Re: The State of Go

#194

Post by XorNot »

jrochkind1 wrote: post #110

Yeah, I dunno, the github PR 'culture' I've engaged in has often in fact been about code review. I don't see any problems with forking a repo publicaly to make a PR (what is there to hide?), am not really bothered by merge commits (and in some cases they are actually quite useful, some people prefer them, it's a point of some contention), and I don't really understand what they mean by 'Comments are sent as they are…

Moreover, you can fork a repo, then work on the actual repo in whatever form you want. Most of my forks are just to maintain public branches, and I have any number of private or unfinished stuff on my home machine.

Re: The State of Go

#195

Post by yawaramin »

MaulingMonkey wrote: post #193
yawaramin wrote: post #177

Earlier quoted context omitted.

Pull request culture is about enabling distributed collaboration, i.e. I don't have push permission to your repo and you don't have push permission to mine, but we can still collaborate by sending each other pull requests and sharing our work that way. It's all about collaboration while not trusting the other person with write access to your repo.

> It's all about collaboration while not trusting the other person with write access to your repo. If I don't trust someone enough to grant write access to my repo, I certainly don't trust them enough to rubber stamp their pull requests.

Nor should you. You treat their pull requests just as you should any code review: you study them and decide whether to approve (accept) them or not.

Re: The State of Go

#196

Post by dsymonds »

zak_mc_kracken wrote: post #191
dsymonds wrote: post #190

Earlier quoted context omitted.

We expect contributors to sync and run all the tests. The public forking is the weird and unnecessary part. Gerrit is the alternative used, and contributors have a full local clone of the git repo, with their commit, and that's private on their machine until they push it to Gerrit for review.

What is so disturbing about the "public" part that it's worth discarding the whole approach?

No-one said "disturbing". It's weird if you've come from an environment where you do your individual work in private, and only show it to people when it's ready to be committed/merged.

No-one said that that point alone is worth discarding the whole approach. You're nitpicking a single bullet point from around a half dozen points that stacked up.

Re: The State of Go

#197

Post by thockingoog »

Mithaldu wrote: post #41

Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…

I'll concur that the GitHub code-review UX is atrocious. Having used a small number of other code review tools, I can't fathom how GitHub's tooling is so brain-damaged.

It does a few cute and clever things, but I totally agree with this slide deck's gripes. Email and GitHub are not really compatible.

Re: The State of Go

#198

Post by jaimeyap »

frowaway001 wrote: post #158
jaimeyap wrote: post #131

Earlier quoted context omitted.

A lot of people commenting here probably haven't had the experience of working with mature pre-submit code review tools. It's funny how much of an opinion people seem to have about things they don't know about. I'm shocked at how bad Githubs PR review UI is given how much funding they have had for so many years. Even abandoned side projects like Rietveld have vastly better review UIs and workflows for larger patch se…

I don't see a problem. Google people use what their NIH-filter-bubble tells them and the rest of the world uses Git(Hub). Everyone is happy.

I probably sounded overly dismissive of github. Which probably isn't fair. But I'll leave my post un-edited for posterity.

I use github every day for work. There are lots of things it gets right. But if you want to work on a project where you more or less have a central repository, take contributions from external and internal contributors, and have a strict policy of pre-submit reviews for individual commits to master that vary in size and complexity, then you want a tool that is 'code review centric'. That is, something that supports comment drafts, back and forth exchanges across many files, and notions of iterations as the reviewee responds to feedback. Github is lacking in this regard, for all the reasons the Go team pointed out. I mean... they just recently shipped side by side diffs!

The main thrust of my comment was to point out that lots of people in this thread are criticizing the Go team's choice to use Gerrit instead of Github, and the points they make seem to stem from an ignorance of both tools like Gerrit, and of workflows that work well that aren't pull requests. It's a bit of "what you see is all there is" where all they've seen is Github. And statements like "github is good enough" seem overly dismissive of the decisions of a lot of very smart people on the Go team.

For folks that are familiar with Gerrit and still poopoo their decision to use it. Well... we can agree to disagree :).

I'm rooting for Github. I want to see it get better so I can stop running a separate code review tool for my own projects! But it's got a ways to go still.

Re: The State of Go

#199

Post by pacala »

crawshaw wrote: post #73
zellyn wrote: post #5

Earlier quoted context omitted.

> Most Googlers I've spoken to despise this guy's reactionary lordship over the project Wat‽ Talk to more of us. From where I sit (ie. not related in any way, just an observer who happens to be a Googler) the go team is fantastic.

That's really nice of you to say. Thank you.

As a Xoogler with some exposure to Go, let me second:

* Go is an excellent tool for getting things done. * Go is great for reading large amounts of other people's code. * Go team is truly impressive. I expect Go to only get better.

Re: The State of Go

#200

Post by piotrkaminski »

jaimeyap wrote: post #198
frowaway001 wrote: post #158

Earlier quoted context omitted.

I don't see a problem. Google people use what their NIH-filter-bubble tells them and the rest of the world uses Git(Hub). Everyone is happy.

I probably sounded overly dismissive of github. Which probably isn't fair. But I'll leave my post un-edited for posterity. I use github every day for work. There are lots of things it gets right. But if you want to work on a project where you more or less have a central repository, take contributions from external and internal contributors, and have a strict policy of pre-submit reviews for individual commits to mast…

I'm curious -- which code review tool are you using for your projects? Gerrit, or something else?
Post reply on HN