Hi, GitLab CEO here. Installing GitLab should take only 2 minutes with the Omnibus packages available on https://about.gitlab.com/downloads/

Upgrading GitLab is as simple as:

    sudo gitlab-ctl stop unicorn
    sudo gitlab-ctl stop sidekiq
    sudo gitlab-rake gitlab:backup:create
    sudo dpkg -i gitlab_x.x.x-omnibus.xxx.deb
    sudo gitlab-ctl reconfigure
And we're working very hard to make sure this is a flawless, uneventful & boring process for 100% of the users https://twitter.com/PentiumBug/status/569930640725946368 We're also working on a package server so you can just use apt-get to upgrade.

+1 (Or can I give +1million?) to Gitlab.

GitLab is now one of the core products in our business and we (Devs, Ops and PM's) love it.

For Ops: * It's easy to deploy.

* It's easy to manage / support.

* Gitlab-CI now builds all our Docker images which is great.

* Gitlab-CI runners are a pain in the ass to deploy.

For Devs:

* It's workflow and code review is great.

* GitLab CI is a great alternative to using external CI systems / Jenkins.

For Everyone:

* It's wiki is great (and getting better over time).

* It's fast.

* It's very reliable.

* The community is great as is GitLab as a company.

* GitLab's momentum of the last 6 months has been great and shows no sign of slowing.

We don't have it hosted on very powerful hardware but it flies - so much faster than using Github, or our old internal setup of Gitolite+Gitweb/Redmine

I tried out Gogs yesterday and this is what I took away:

* It's incredibly fast.

* It's incredibly lightweight.

* At first it looks 'pretty' but quickly you it becomes clear that it's actually quite unintuitive to use (for example, it took everyone that tried it here longer than it should to find how to log a new issue).

* There is no wiki.

* There is no CI.

* There is no Debian package which would be nice.

* It's written in a language that most Devs / Ops can't contribute to or bug fix.

All and all, I'm very excited about Gogs for my personal git hosting at home / on my VPS' - but I don't think it's even close to providing the system that GitLab has at present.

Thank you for sharing your points: for me this is actually quite an endorsement of gogs (But then, I'm not looking for an alternative to gitlab).

> * There is no Debian package which would be nice.

True. AFAIK there aren't any packages in Debian that depend on go/golang yet, not even in sid. That doesn't mean one can't make out-of-band debs, of course, but gogs unfortunately isn't alone here. Does anyone know of any util/tool/package in go (other than golang) that's packaged for Debian?

> * It's written in a language that most Devs / Ops can't contribute to or bug fix.

As opposed to what? I'd think being able to patch something in go would be within the grasp of most Ops, and also most devs?

For sure - it's got lots of promise and we are by no means bound to what we've bought into - we'll use whatever's best, at the moment that's Gitlab.

To clarify I didn't mean that it would be nice to have packages that are maintained by or in the default Debian repo - but an apt repo for the project would be nice.

I've found Go a pain to read and hack with - Ruby and Python however are a lot more readable and any of our ops or devs would feel confident in finding / reporting bugs in either.

Actually, I was wrong (also in my sibling comment):

http://gogs.io/docs/installation/install_from_packages.md

(Linked from the github page). So there are debs available of gogs. Trying to figure out how to build a deb from the git repo, but if all you want is upstream binary debs, you appear to be covered.

See this stackoverflow q/a -- it appears to contain most of the current highlights. Basically Ubuntu has started packaging a few go apps, and fpm[f] seems to be an ok alternative in the meanwhile:

http://stackoverflow.com/questions/15104089/packaging-golang...

packager.io (which upstream googs uses) seems to be a nice way to just get packages out there, but as far as I can tell it's pretty well walled-off behind a service, so no easy way to build locally, off-line, or without using packager.io etc. In that sense it strikes me as a poor choice for Free software, as there is no promise that things will continue to work, or can be made to work, long term.

[f] https://github.com/jordansissel/fpm