Kinda scary how de facto Github has become, that external tooling is discouraged. Github is a bad issue tracker, a bad code review tool, an ok wiki and a bad distribution platform. Still, one has to mostly use the whole package to get contributors.
One thing Github does that really bothers me is that if your paid account lapses, you must pay to get your private repos back. You don't have the option to simply set your repos to public. The only options Github gives you is pay money or lose your repos. As far as I care, that's practically extortion. So I moved to Gitlab.
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.
BitBucket is plenty popular as well, I run into projects that are on there instead of GH for Python. I kind of prefer BitBucket to GitHub the only thing GitHub does right is their "Explore" section which I don't think BitBucket has (or GitLab?) but that's about it for me. I don't care where one hosts code, as long as it's not some obscure server.
For a long time BitBucket was the only one with the protected branch feature that could prevent history rewrites on a branch by branch basis. Github finally added it after the force push that blew away so many critical repositories.
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.
I use Gitlab and just have it push to Github, then disable issues/wiki/whatever else I can there, and add a link to the Gitlab repo in the description.
BitBucket is my default for pet projects nowadays, and it's also what I typically recommend for professional work. Better pricing, direct access to Atlassian's tools (which have their own issues, but are generally pretty popular), and the "projects" feature is nice (I just wish it was usable for personal repos rather than being an organization-only feature).
We have BitBucket at my job, I think because I showed my code during an interview through my BitBucket account it probably made me look good to my interviewer (now my boss) due to familiarity with tooling we already have. I can use any of them honestly. I use GitLab for private pet projects and BitBucket when I open source my projects, and then mirror to GitHub.
GitLab has an explore section https://gitlab.com/explore but it isn't as good as GitHub's one. Both to having less projects and us spending less time on it.
Oh that's nice, found some interesting projects there, thank you. I use all three git sites, I mostly use BitBucket because it was the first one I found with free git repositories, but I use GitLab now for private projects. Thank you again for coming on here and always being willing to respond to anyone asking about GitLab I always appreciated that about you.
GitHub has always had far superior code search features. BitBucket is gradually trying to add these, but they still pale compared to GitHub. I love just going through a repo by searching for things.
I'd also be interested in knowing. I also feel GitHub's issue tracker is not right for a large project like this.
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.
GitLab's threaded, resolvable discussions is very efficient, especially if you enable mandatory resolution before merge, forcing you to create issues for unresolved ones through the related button, guaranteeing you never loose track of something that should be resolved. I have a hard time going back to GitHub because it's so useful.
That's great to hear, I haven't used GitLab for code review before. I struggle to use the rest of GitLab, but it's improving all the time so we might consider it once it's up to the usability of GitHub for the rest of the experience.
I'd recommend looking at RhodeCode for code-review. It has few unique features like pull-requests versioning allowing partial diff between updates, todo notes. Team looked at few gerrit features and want to port it too to make code-review much better.
so you don't mind having review comments disappear if somebody updates the PR, and it doesn't bother you not being able to say in a comment "this needs fixing" in a way that you can mark it fixed later on (and without marking as fixed the PR can't be merged)?
Github reviews are fine for a one-and-done merge, but for a back & forth review I really wish it had the above...
This looks like a good spot to plug Reviewable (https://reviewable.io), which addresses the disappearing / untracked comments issues and more, while still integrating with GitHub rather more gracefully than something like Gerrit. While GitHub's PR review tooling has improved in the last year there's still a fundamental difference in philosophy such that Reviewable isn't lacking for customers. :) (Disclosure: I'm the founder.)
I've looked at Reviewable several times, and I'm afraid to say I've never been convinced to try it. There's obviously a huge cost to moving team process over to a new tool like this, but also I just found it more difficult to understand what was going on compared to GitHub reviews, so it wasn't particularly compelling for us. Hope you don't mind the candid feedback!
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? For this purpose alone I think the current approach is something that Google will not get rid of.
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.
> 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
>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.
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.
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.
> 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.
>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
> 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?
>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.
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)
>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?
One can become an expert on compiler developer precisely because they have little tolerant for convoluted BS processes.
The article addresses how Google is already using GitHub with Kubernetes. Looks like Dart does too from glancing through the GitHub. If you're worried about external services going down, you make an internal mirror. You don't force the whole workflow to go through your system.
Or you just don't use an external service in the first place, minimizing your dependencies, which you arguably should be doing anyway?
They are not forcing anyone to go through their system, it is completely your choice to either help the project or not.
> Unfortunately the epic comment thread, very talky, none of the key stack holders involved, largely irrelevant chatter... 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).
I doubt the GitHub thread was "a long poem, typically one derived from ancient oral tradition, narrating the deeds and adventures of heroic or legendary figures or the past history of a nation"
The adjective is obviously. derived from the noun, and as such had much of the same meaning originally: "relating to or characteristic of an epic or epics: our national epic poem Beowulf."
And no, I'm not proud of having to weigh in on this subject.
This is insane, considering the process before github was "send a patch by email".
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.
The "just use GitHub" mentality is harmful groupthink. How about being open to learning other tools? Locking yourself into a single ecosystem and bothering otherwise productive people who don't buy into it is how we get SourceForge.
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.
For high stakes projects, I feel there's an aspect of "choose your battles wisely". Is relenting in some dimension going to harm the overall goal? IIRC Go was hassled off of mercurial and onto git, so there's a bit of a fractal too.
It's true that Gerrit's workflow is a bit unusual, but even though I had no experience with it, I managed to setup the environment and create a review request for Golang in under an hour. When it comes to contributing to a programming language, I think this is pretty friction-less.
Sure it would be. Mostly because I use Github every day. The first time I tried to create a pull request it probably took me almost as much time to figure out how Github works.
But compared how much time is saved for reviewers by having a better tool, I think 1 hour for each new contributor is reasonable.
In my experience, there are no debates so fraught and vicious as those over version control platforms.
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.
> 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.
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.
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.
I've contributed a small patch to Go not that long ago and it was quite straightforward, I don't get why it has to be changed. Plenty of people have used the current workflow for years now...
Possibly off topic, but this prompted me to take a long overdue re-peek at git-appraise (distributed code review tool, written by google in go). I notice there is now a git-appraise-web. It looks pretty nice (exceptionally minimal :-) ), but their demo lacks any comments to see how it might work in collaborative form.
Does anybody use git-appraise (and especially a web client) and have any comments?
the proposal is cute and funny, basically the author argues that to make the contribution and governance process more open, everything has to be done on github to be more closely aligned with what project X,Y,Z are doing.
that is not open or free, that is the exact opposite of being free and open.
If one wants to see the merits or at least the experiences of a major language from a commercial entity going open source on GitHub, where all discussions, language features, issues, and code itself is in that one place, take a look at Apple's Swift.
Edit: Looks like Swift doesn't use GH for issues any more.
I wonder if Google really loves Gerrit, or if it’s just a legacy NIH attachment and some of Google’s graybeards just refuse to let it go.
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 joy of decentralization to my mind is not a total avoidance of centers, it is resilience against those centers becoming obnoxiously or harmfully authoritative.
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.
(Github has other strengths, though)