[sytse]

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.

[txu]

Gogs looks quite polished and it might attract people who needs to setup a new server. But once you setup your workflow you don't want to worry about it for a while because you want to focus on the actual work. Switching the tool is of the least concern unless the old one broke.

I've been using Gitlab to manage all my personal projects and I am grateful of how many features and constant improvements I get for free. Lots of free software have terrible UIs, eg. ReviewBoard, Jenkins, Graphite etc (these are great projects btw, just the UIs still look like from 2000). But Gitlab's UI is modern, elegant, and shows me all the activities on my projects. So I check my projects regularly and feel encouraged to work on them. Granted I can't tell if it scales for big teams but it is not an issue because I only share the instance with a few friends.

It has ran worry-free for me for almost two years besides occasional updates because I wanted the latest UIs and it helped me focus on coding. Thanks for the great work!

[sytse]

Hi txu, glad to hear your enjoy GitLab. An GitLab certainly scales for larger teams. We have a customer installation with more than 10k developers and there are more than 30k active users on GitLab.com

And we're spending more time to polish the UX to make sure it looks good.

[mrmondo]

+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.

[e12e]

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?

[mrmondo]

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.

[e12e]

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.

[e12e]

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

[mrmondo]

I've used FPM for small things that aren't too complex but I certainly wouldn't trust the Ubuntu packaging team.

[sytse]

Thanks mrmondo, glad to hear you like GitLab!

[jordigh]

Heh, "simple"...

http://blogs.msdn.com/b/oldnewthing/archive/2015/03/10/10598...

Nice to hear you're working on something simpler than simple. :-)

[sytse]

:) I agree, it should really be one command. We'll look at making it better, https://news.ycombinator.com/item?id=9212456

[mrmondo]

Pretty ripe coming from MSDN...

[lorddoig]

I put GitLab on a personal server a week or two ago for some stuff, and I'm sorry to say it but the overwhelming takeaway from that experience was watching it hog memory and spawn what felt like a million processes which somehow lingered for days after uninstallation until I noticed them. This thing runs one process, idles at 0.0% CPU, and is blazing fast in <450MB memory - when all you want is a nice git GUI for a small group it seems pretty perfect.

[sytse]

I'm sorry to hear you experienced stray processes. Did you use the Omnibus packages? Did you use gitlab-ctl stop?

[y0ghur7_xxx]

nice. the problem i have with gitlab is not much the upgrage process anymore, but the fact that you don't accept push requests from the community of features that you implemented in the enterprise edition. for example the git hook stuff.

i hope someone who has the time and the skills forks gitlab and merges push requests of new features, even if they are already implemented in your pay-for version.

[sytse]

Can you link to the merge request you refer to? Merging something depends on the quality of the implementation and the use case. We don't say that git hooks will be EE forever and we try so evaluate each merge request on its merits.

[y0ghur7_xxx]

> We don't say that git hooks will be EE forever and we try so evaluate each merge request on its merits.

Seems like you sad exactly that a while ago:

"We are unlikely to merge this functionality in CE because there already is a nice implementation in EE."¹

It's your repo. You can do whatever you want with it, no need to merge PR for features that are already in your EE edition. That's why I hope someone forks it, or something better comes around.

¹https://github.com/gitlabhq/gitlabhq/pull/6883#issuecomment-...

[sytse]

Thanks for the link. In the lines before the quote I said "This PoC still leaves a lot of work. Right now the controller writes files, this should be done though gitlab-shell."

We where unlikely to merge it because the code quality was low, if someone makes a good implementation we're more open to merging it.

BTW The pull request in question uses the git hooks to do code linting. I think it is a better user experience to do this in GitLab CI in parallel with the rest of your tests https://about.gitlab.com/gitlab-ci/

[y0ghur7_xxx]

> We where unlikely to merge it because the code quality was low

Oh, so it's not because "there already is a nice implementation in EE." Ok.

It's also in disagreement with what you sad on the EE announcement:

"If the community develops code for a feature that is already in EE we will certainly consider merging it or open sourcing the EE feature. This depends on several factors including the seriousness of the merge request, the number of GitLab users requesting this feature and if the feature is useful for small and medium size organizations."¹

For at least this particular feature the community is clearly interested (just by looking at the +1 on the github issue), but you continue to handle the CE version as "demo" software for EE. Which is ok. Just say so clearly.

¹https://about.gitlab.com/2013/07/22/announcing-gitlab-enterp...

[sytse]

Hi y0ghur7_xxx, I think the comment you just quoted is the most extensive and the best thing I've written about this. All my other comments are shorter versions of that comment in my mind.

The CE version is not demo or crippleware. It is a fully functioning version of GitLab without any restrictions that is just as performant and secure as the EE version. The only difference is that the EE version has more features.

[coldtea]

>Oh, so it's not because "there already is a nice implementation in EE." Ok

That they said "there already is a nice implementation in EE" doesn't automatically mean they also intended it to remain EE-specific forever.

It could be also be read as "we won't merge this in the free edition, as we already have a nice implementation in EE we might merge later".

[mrmondo]

I agree with this actually - the whole public Gitlab CE vs EE repos and management is a bit of a mess - it seems to be getting better though.

[jlas]

Looks like you need a `gitlab-ctl upgrade` command

[sytse]

Good idea, I made an issue https://gitlab.com/gitlab-org/omnibus-gitlab/issues/471

I also noticed that the current instructions were not very copy-paste friendly and made some small changes to remedy that https://gitlab.com/gitlab-org/omnibus-gitlab/commit/51d51fe1...

[tomjen3]

Why not just do apt-get update like (substantially) everybody else?

[sytse]

We're working on having a packagage server. We wanted to have something for multiple platforms that also supports our Enterprise Edition. We've decided to go with PackageCloud.io on-premises and it will be up in a month. Currently we're doing 1TB+ of package downloads per week.

[drinchev]

Congrats about GitLab it's amazing, you guys rock.

Do you have any plans for decreasing the resource footprint. I think the OP has a strong point in stating that it is a bit of a RAM drainer.

[sytse]

Thanks! We're looking into reducing the resource footprint, but it is not easy. Right now we're working on a package that makes GitLab easy to install on a Raspberry Pi 2, a request that we've seen a few times of the last few weeks.

[ocdtrekkie]

Another possible option is the Sandstorm.io port of Gitlab. It can be installed as easily as a mobile app. :) That's where I found out about/first tried Gitlab.

[sytse]

Yeah, thanks for the hard work of David Renshaw from SandStorm for making that work.

[handelaar]

Just FYI you're now every grandchild comment of this grandparent.

Could you maybe stop shouting GITLAB! all over this thread that's not about Gitlab?

[ocdtrekkie]

In fairness, when someone makes a post specifically saying "replacement for :product:" it's probably fair game to discuss the merits of the product being supposedly replaced.

I mean, if only every CEO was connected enough to read like almost every comment or criticism about their product online...

[yawaramin]

Whoa, easy with the thread policing. He's specifically replying to people asking him questions, not randomly shouting.

[sytse]

OK, I'll reduce the volume a bit, thanks for the feedback.

[ekmartin]

You're answering specific questions about your product, nothing wrong with that.

[xvilka]

Not directly about installation process - but about integration with external tools. Looks like you're focused on the SaaS tools, rather than selfhosted ones. Integration with application like Kandan [1], rather than locking with HipChat would be awesome too. And/or Jabber integration also could help a lot. Thank you for the awesome work you're doing by developing GitLab!

[1] https://github.com/kandanapp/kandan/ [2] http://feedback.gitlab.com/forums/176466-general/suggestions...

[sytse]

Most integrations are contributed by the community. I must admit that KanDan is very interesting and it is good to see it is still alive. It would be awesome if someone could contribute an integration for it.

http://feedback.gitlab.com/forums/176466-general/suggestions... is marked accepting merge requests, we would love to see this too

[AbraKdabra]

I love GitLab, I'm using it for my freelance projects, but there's one thing that I encountered that is crucial, choosing which web server you want to use, I have apache2 installed at work and installing the gitlab omnibus package which uses nginx breaks my apache installation and I didn't find it easy to use both alongside.

Besides that, GitLab is fantastic and I thank you for that.

[sytse]

Glad to hear you love GitLab. If you want to use the Omnibus packages with Apache please see https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc... Edit: I tried to make this easier to find with https://gitlab.com/gitlab-org/omnibus-gitlab/commit/e2f9d17d...

[ancarda]

I just tried setting up GitLab and after running reconfigure it seems to just hang. Is my sever (2GB Linode) too slow for GitLab?

[sytse]

2GB should be enough, can you email [e-mail] and reference this comment in your email?

[ancarda]

Thanks, I just sent an email.

[UserRights]

It would be great to have these packages available for the fantastic https://alpinelinux.org Have a nice day!

[sytse]

Thanks! I can't promise anything but we'll take your suggestion into account.