Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

71–80 of 325 posts

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

#71
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 usability, perhaps...

[1] I'm not actually quite sure if there is a specific command for that format. Though it should be easy enough to have a third party solution that uses a format through email.

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

#72
post #26
post #20

> "Right now GitLab.com is really slow and frequently down. This is because of fast growth in 2015. We are working to improve it in the first quarter in 2016. For now please consider downloading GitLab and using it on-premise for a fast experience." Is this a joke? I mean for people looking for free private Git hosting, there is Bitbucket. This statement is like saying "free, but not really, really." The fact is if I…

I think they mean you can download the free community edition and host that. Why do you feel you need to pay for the EE version?

While I dont agree with the GP, from the phrasing its clear they mean that the project would be hosted on Gitlab's servers.

In my opinion its nice to have the ability to host it yourself and it was the primary feature attracting me to GL, followed by it looking user friendly for a few people I am working with who are not shell people, and what finally sold me is they clearly have a team which is focused on making the product better.

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

#73
post #39

Earlier quoted context omitted.

I think you are right about how GitLab started. There is, and there should be, a lot of frustration about the biggest open source hub (GitHub) not being open-source themselves. This feels backwards and creates a harsh dictatorship that shouldn't be. GitLab tried to solve that by making an open source version and because it now can be improved upon by everybody new features start to appear. I love the self hosted aspe…

> A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub Believe me, we would too and we are sorry about the current state of GitLab.com. We are working on improving performance in Q1 2016: https://gitlab.com/gitlab-com/operations/issues

It may be more stable than GitLab, but I have never thought of GitHub as "rock stable."

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

#74
Meanwhile, Phabricator has implemented all of these (and even more).

Custom templates: https://secure.phabricator.com/book/phabricator/article/form...

Votes: https://www.mediawiki.org/wiki/Phabricator/Tokens

It's better in almost every aspect than GitLab and GitHub.

See https://en.wikipedia.org/wiki/Phabricator for an (incomplete) list of open source projects using it.

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

#75
post #55

Before you think of switching to GitLab, look at their status Twitter account over the past few months. They've had a lot of down times. They run on Microsoft Azure.

> They run on Microsoft Azure.

What does this have to do with anything? Are you suggesting that service run on Microsoft Azure are not stable?

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

#76

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…

Your account on gitlab.com is completly free and permanent unless you decide to delete it yourself.

The 45 day trial is for the case when you want to host gitlab-ee yourself on your own server.

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

#77

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…

Visiting www.gitlab.com redirects me to https://about.gitlab.com/. There are three big options:

1. Community edition 2. Enterprise edition 3. On our server

The 3rd option has this text: Free hosting for private repos? Sign up to get unlimited repos and collaborators.

Clicking on Sign up takes me to https://gitlab.com/users/sign_in which has clear options to sign in or sign up. It also has the text: GitLab.com offers free unlimited (private) repositories and unlimited collaborators, please sign up or in on the right.

In lesser words, it seems pretty clear-cut to me. They offer unlimited free hosting for your repos. I did not see any trial period anywhere. Maybe you went to the Enterprise option?

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

#78
post #47
post #9

With VideoLAN, we're not on github, but I believe we fit the 'large open source project' description. We host VLC, FFmpeg, x264 and quite a few related libraries. For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure. And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting th…

> Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them. On a technical level that seems an impossible distinction to make. Someone want…

Yet, there is still differences. Allowing only "fork" is a good and easy thing.

Having a fork that delete everything and start a new projet is easy to detect and label as spam. (there will always be abuses, but it's okay as long as you can mitigate/moderate)

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

#79
post #47
post #9

With VideoLAN, we're not on github, but I believe we fit the 'large open source project' description. We host VLC, FFmpeg, x264 and quite a few related libraries. For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure. And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting th…

> Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them. On a technical level that seems an impossible distinction to make. Someone want…

It would still send a signal of "please don't do that" - and could be "enforced" with some change/diff tracking in a cron job (all files changed removed - prompt someone to have a look, or just freeze access for a week/month then schedule for deletion).

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

#80

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 free. GitLab EE costs money and has a 45-day trial.

Post reply on HN