Golang Proposal: Just Use GitHub(github.com) |
Golang Proposal: Just Use GitHub(github.com) |
(Github has other strengths, though)
Luckily, Github screwed up and temporarily unlocked my private repos, letting me grab the ones I didn't have locally and move them to Gitlab.
No opt-out option, no deal, Github. This is something that students should particularly take note of, because it applies to Github Education accounts, too.
https://help.github.com/articles/unlocking-a-locked-personal...
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.
As for the code review tools though, I've not yet seen something that I feel is materially better than GitHub + PRs + some bot-enabled automation. I understand that many people _prefer_ things like Gerrit, but I've found the difference to mostly be opinion, and that Gerrit can be a significant problem in getting contributions - it's quite hostile on first use.
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.
Is a case in point of why github isn't the answer for everything.
Many of the important stakeholders, both those employed by Google and those who are not, are weighing in on the topic.
And the comment thread looks fairly similar to the mailing list discussion of any moderately controversial issue, which is not unique to Github (or even the Go project).
Robert Griesemer, Ian Lance Taylor have put in their comments (apart from other core contributors).
So, I would say this statement is false now.
I thought the original meaning was gone.
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.
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.
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.
CLA was very painless too.
But compared how much time is saved for reviewers by having a better tool, I think 1 hour for each new contributor is reasonable.
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.
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.
That said, 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 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.
Does anybody use git-appraise (and especially a web client) and have any comments?
jimmyfrasche commented
The language spec is easier to read than the contribution guidelines
Also, a "Comic Sans" website makeover would severely cut down on the golang community's hipster ratio.
that is not open or free, that is the exact opposite of being free and open.
Not in the religious/GNU sense.
Edit: Looks like Swift doesn't use GH for issues any more.
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.
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?
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.
As you mentioned, the dubious part is if it captures control of all of your "meta" processes too.
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
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.
No.
Github is a mirror, the canonical git repository is at https://go.googlesource.com/go.
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.
One can become an expert on compiler developer precisely because they have little tolerant for convoluted BS processes.
I'd never host my own stuff on github since gitlab is good enough but doesn't lock me in to as proprietary web service.
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)
As an adjective it's something that's "extending beyond the usual or ordinary especially in size or scope".
And no, I'm not proud of having to weigh in on this subject.
1. relating to or characteristic of an epic or epics.
2. heroic or grand in scale or character.
"his epic journey around the world"
Here's my source: https://www.merriam-webster.com/dictionary/epic
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.
Becoming an expert on whatever custom commit process a project has does even less to make you a compiler hacker.
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.
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
Github reviews are fine for a one-and-done merge, but for a back & forth review I really wish it had the above...