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

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

Post reply on HN
Print view View original

241–250 of 325 posts

Re: Dear open-source maintainers, a letter from GitLab

#241

Post by mdw »

dordoka wrote: post #216
mdw wrote: post #183

I've recently made an iOS App that integrates with GitLab. The people at GitLab have been incredible, they respond to my issues, improve the API with every release, I didn't expect this level of awesomeness when I started the project. What's great about GitLab, there's a release on the 22nd of each month, so you can depend on pretty much continual improvement. Even if you don't think GitLab is suitable for your Open…

Thanks for building Trident! Happy customer here. Gitlab servers work really well and is super fast. Patiently waiting for the Github servers functionallity to be on par with the Gitlab one :)

Appreciate this compliment :) Please open any issues you see with the App in the issue tracker, helps me prioritise new features and candid feedback helps!

Re: Dear open-source maintainers, a letter from GitLab

#242

Post by reledi »

akerro wrote: post #13

My company with ~300 developers are moving to Gitlab in the next few months. Today our CTO/PM shared opinion about Gitlab and he was very happy we're doing it, even better I recommended it to him :) I'm a Gitlab users for a few years now, personally I like it much more than Github, one of the reason is that I fear that Github contains too many projects and gains too much control over OSS, I also dislike their CoS. Go…

> one of the reason is that I fear that Github contains too many projects and gains too much control over OSS

I don't understand this fear. All repositories on GitHub can be hosted elsewhere. Moving metadata (e.g. issues, milestones, PRs, etc.) is more difficult but mostly possible.

Disclaimer: I like that GitHub is the "central" place for OSS, it makes my life much easier. I know how to use the product very well and it's convenient having almost every project that interests me available there.

Re: Dear open-source maintainers, a letter from GitLab

#243

Post by glandium »

throwaway999888 wrote: post #71
glandium wrote: post #5

Just for this, I'm tempted: One issue that was raised several times was the ability to not create merge commits. In GitLab you can, as an alternative to the merge commits, use fast-forward merges or have merge requests be automatically rebased. The main thing keeping me from actually doing it is the network effect... and this: Disadvantages Right now GitLab.com is really slow and frequently down. This is because of f…

There is already built-in support for pull request[1] and patch based workflows in Git itself. Why do we need to wait for, and choose based on, hosted services providing things like that? EDIT: for more clarity; using pull requests and patches with Git itself means that it simple to rebase or whatever, since you're just working with branches and patches directly. Or am I missing something? Other than something like u…

I hate that github does pull request merges with --no-ff, so what happens is that I manually pull the PR, merge it locally, and push. Github is nice enough to notice that the PR was merged, so its status is appropriately closed (if that was a fast forward, I don't think it detects rebases), but that makes me have to go out of the browser to start typing commands when I could have just clicked a button and be done with it. Essentially, it's a smoothness problem.

Re: Dear open-source maintainers, a letter from GitLab

#244

Post by Jedd »

pmilot wrote: post #194
Jedd wrote: post #82

Earlier quoted context omitted.

> This attempt by the Gitlab folks to ride the Github dissatisfaction > wave seems a little low-brow. There's a github dissatisfaction wave? Anyway, opening sentence of gitlab's open letter: "The letter of GitHub’s open source community is clearly not addressed to us, but we’re thinking a lot about the issues that were mentioned in it." Does that cover your concerns? I think if github was the free software entity, an…

"Wave" might be too strong a word, but I've seen three or four posts on HN in the last few days that were pretty critical of Github's closed source nature and insufficient transparency. I'm not sure why offering a free software edition somehow gives you a pass. Both Github and Gitlab are commercial entities as far as I know. Anyway, my concern wasn't a big deal, I was just a bit taken aback at the opportunism. In ret…

Fair enough. I feel like there's been stories / sentiment along this line for a while, though apart from Microsoft's ChakraCore announcement last week (?), the only two specific stories I recall from last year were about github's valuation (US$2B) and when they threatened to remove someone's repository because it contained the string 'retard'.

You're right that both github and gitlab are commercial endeavours - obviously very much in the same space - so I'd expect them both to pop up in any discussion about bug & feature trackers, community involvement, etc - especially if there's the potential to improve their business.

On the other side of the coin, I'm curious why Github seems to often get a pass by the free software community.

Re: Dear open-source maintainers, a letter from GitLab

#246

Post by jacobsenscott »

glandium wrote: post #5

Just for this, I'm tempted: One issue that was raised several times was the ability to not create merge commits. In GitLab you can, as an alternative to the merge commits, use fast-forward merges or have merge requests be automatically rebased. The main thing keeping me from actually doing it is the network effect... and this: Disadvantages Right now GitLab.com is really slow and frequently down. This is because of f…

I think taking the conservative approach of not re-writing history (--no-ff) is appropriate for a service like github. It is easy to ff merge PRs from the command line.

Re: Dear open-source maintainers, a letter from GitLab

#247

Post by timv »

DouweM wrote: post #80
imonabout wrote: post #67

I don't think the fact that GitLab is free for basic users is very discoverable from the site. You've got the "features" tab, which leads to what seems to be the option of downloading a community edition, which makes it look like GitLab is only offering the code itself but not hosting from their, and the enterprise edition for some licensing fee (I suppose). Then you've got "sign in", but no "sign up", which leads me…

Hmm, the front page ( https://about.gitlab.com/ ) lists "GitLab.com — On Our Server — Free hosting for private repos? Sign up to get unlimited repos and collaborators. — Sign Up", but I get that it's a bit confusing that the features and pricing pages don't mention anything about it. To clear things up: GitLab.com is completely free, with unlimited projects and collaborators. GitLab CE is open source and completely f…

I definitely think there's a discoverability issue there.

1. The Hosted CTA is the right-most one. People don't read that one. Eyes naturally go to the first CTA, and then compare it to the 2nd one. Based on the first 2, I expect the 3rd one to be another downloadable package, not a hosted option, so I don't read it.

2. The top nav-link is "gitlab.com" not "hosted service". If I don't know that gitlab.com is a git hosting service, I'll never look there.

3. As mentioned, features + pricing don't mention gitlab.com, so once you get off the front page, you lose any hints of a hosted option unless you know what the "gitlab.com" link is for.

4. The first headline that my eyes go to below the fold is:

  Self-hosted, scalable and updated monthly
That implies to me that "gitlab" is (exclusively) a self-hosted product, and isn't available as a SaaS option. Yes, it does also say "Or use our free SaaS GitLab.com" but you can't really expect people to read the text immediately below a headline that (effectively) says "not what you're looking for"

Right now, since you're advising people to go self-hosted rather than gitlab.com, that might all be working in your favour. But when you get the performance + reliability of gitlab.com sorted out, I'd strongly advise you to make the SaaS option a lot clearer.

(I realise that I could submit a patch to index.html, but I don't think my 10 minutes of hacking is going to get you to the best outcome)

Re: Dear open-source maintainers, a letter from GitLab

#248

Post by harel »

sytse wrote: post #132
castell wrote: post #113

Earlier quoted context omitted.

Reading their Twitter status messages. Microsoft sponsored Azure for Gitlab. Between Oct and Dec they were on Azure, and they had major issues with the Azure platform, pretty unreliable for their use case. Gitlab switched to IBM Softlayer because of that experience. Read yourself: https://twitter.com/gitlabstatus and https://gitlab.com/gitlab-com/operations/issues/17

Although we planned to switch to Softlayer we're still on Azure. It has given us a hard time, but in the last few weeks things have gotten more stable. Our availability is better (fingers crossed) but our speed is still unacceptably slow https://gitlab.com/gitlab-com/operations/issues/42

From first hand experience, Softlayer has been nothing but fantastic to us over the last few years, and cost effective.

Re: Dear open-source maintainers, a letter from GitLab

#249

Post by nate148 »

radlad wrote: post #234
rplnt wrote: post #42

Earlier quoted context omitted.

There's also Stash (now renamed to BitBucket Server (edit: fixed name, as pointed out in the reply)). It does not include some of the features (such as issue tracking), and I think rightly so. I haven't used GitLab for maybe 2 years now, so I can't compare the two.

To be clear, it doesn't support issue tracking because it is an Atlassian project. Issue tracking is done through Jira, another product they offer.

Umm no, you are incorrect. Bitbucket does have its own issue tracker like GitHub.. (but it is not turned on by default) and what I am referring to is NOT JIRA Software.

https://confluence.atlassian.com/bitbucket/enable-an-issue-t...

Re: Dear open-source maintainers, a letter from GitLab

#250

Post by georgefrick »

noir_lord wrote: post #180
quaunaut wrote: post #146

Earlier quoted context omitted.

Most of the time, it's because of opportunity cost: The time you're spending building a server, learning how to manage repos, setting up redundancy and just trying to get the thing working, you could've spent on whatever product you were trying to produce, and would likely be much further along with if you hadn't done everything the hard way. That's not to say there isn't educational value, but a common piece of advi…

The opportunity cost on the front side is often worth it but the long term benefit on the back side is you aren't dependent on that SaaS, are running stuff you know something about and have a lot of flexibility. I'm from the old school, I use SaaS/PaaS mostly for stuff I know is painful to do yourself (sometimes file storage, nearly always email) but the rest lives on vanilla boxes configured with ansible (frankly an…

Can you suggest a good way to get started with Ansible?
Post reply on HN