GitLab Enterprise user here. GitLab's open-source policy is one of the major reasons we chose it (along with self-hosting and fairly modern, built-in continuous integration), but the GitLab community could use some additional design and documentation effort.
Things that almost make me want to switch back to GitHub:
- GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.
- GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.
- GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.
- CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.
- Typography could be improved. When you're looking at the issues page all day, this is quite noticeable.
- Slack integration is not great; it dumps links to "GitLab Enterprise Edition" instead of useful commit/changeset stuff like GitHub does.
If the community/GitLab can focus on putting on some of the design polish and service integration polish that GitHub has, GitLab would be a total winner for us, long-term.
The quick reply to your comments is: we're working on almost all of it.
> - GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.
We're working hard on this and focus more and more of our development capacity to this.
> - GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.
There are a lot of improvements coming in this field. Especially the integration and setup of runners is going to be easier. We're hoping to make this a zero-step setup thing.
Same with documentation. Our new GitLab CI maintainer Kamil has been spending a lot of time on writing documentation.
> - GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.
This is interesting, I'm passing it onto Kamil.
> - CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.
This is be interesting to look at. I'm not sure whether we have something like this in the planning, but I'm taking note.
> - Typography could be improved. When you're looking at the issues page all day, this is quite noticeable.
We're worried about adding page load by including typefaces. We might change our minds on this. What OS are you using?
Would Roboto work, for instance?
> - Slack integration is not great; it dumps links to "GitLab Enterprise Edition" instead of useful commit/changeset stuff like GitHub does.
We welcome contributions to improve it. This is not a focus at the moment, but considering the popularity of Slack, we can definitely have a look at this.
Super.. good to hear! Ideally the community can get a little more involved in design/UX too. I'm not sure if GitLab plans to set the tone there first - perhaps that's also on the roadmap.
> Would Roboto work, for instance?
Maybe the typeface isn't so much the issue as the layout? On the issue view, comments and descriptions have different positioning and styling. Also, important information lives above the issue title, which is unexpected.
Being unable to trigger CI builds based on merge requests (which can dispatch a build for a commit ID, but you've probably already pushed that commit) is probably the most problematic for us at the moment.
Maybe it would be cool if GitLab came up with some basic design principles/goals and accepted contributions toward that end. I know we'd be interested in contributions here and there to improve workflow/UX.
> We're working hard on this and focus more and more of our development capacity to this.
No, no, no. :) It's not a development thing, it's a design thing. The good part is that your users are well-defined - developers; you could do a great job there, but don't allocate your developers to it. Hire or contract someone experienced in UX.
P.S. With a good UX work, you might end up not only bettering GitLab's layout but also discovering new, differentiating and truly useful (user-wise) features.
> GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.
I agree out interface can be a lot better. Our first interaction engineer will start September 1 to improve it.
>GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.
There’s a lot of going on in this field. We are listening to people’s user cases and trying hard with the rest of community to extend documentation that will cover them. I agree the test runner registration should give better feedback if there are failures. False positives shouldn't happen, please create an issue if they do.
> GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.
Agree, we have that on our roadmap: allow to run commands in case of script failure.
> CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.
I don't know what you mean exactly. Do you mean you want to test the code that will result after the merge instead of the commit in the feature branch? It would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated). BTW The new build trigger API (to be released in a month) is one of the upcoming features that will allow more build customisation.
> I don't know what you mean exactly. Do you mean you want to test the code that will result after the merge instead of the commit in the feature branch? It would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated). BTW The new build trigger API (to be released in a month) is one of the upcoming features that will allow more build customisation.
No, I want to trigger additional types of tests under two circumstances:
- When a merge request is created
- When additional commits are added to a branch for which a merge request exists
The utility is: I don't want to run integration tests if someone is just pushing to a feature branch - that takes up worker time. But I do want to run integration tests before that feature branch gets merged upstream. Achieving this by having everyone submit merge requests to an intermediate branch doesn't work, because we don't know the integration test result until after the merge to the intermediate branch is done, meaning developers might be trying to push a bunch of failing code to the same branch, just to get integration tests to run.
> But I do want to run integration tests before that feature branch gets merged upstream.
Specifically, the integration tests should run against the version of the source code in the feature branch that the merge request is about. The target branch can be merged into the feature branch to have full coverage of the post-merge status, so the target branch's importance is really minimal here.
> Yes, it would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated).
Actually no, that's not what I was trying to get at. The tests just have to run against the version of the source code in the feature branch. If the integration tests need to cover anything else, it should be inserted into the feature branch manually. Stale branches are their own problem and are quite common, independent of CI-related testing. Running unit tests all the time is fine, but it would be nice if special additional tests can be triggered only for new merge requests and for updated merge request source branches but not feature branch pushes unassociated with merge requests.
Yes, it would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated).
Question for you: as a GitLab Enterprise user, knwoing that GitLab has CI built-in, is there a situation in which you would buy CircleCI to go alongside it? Obviously we (we being CircleCI, founder here) have GitHub Enterprise support, and I wonder if we should build GitLab Enterprise support too.
> is there a situation in which you would buy CircleCI to go alongside it?
Well, we were using circleci for a while until the switch to gitlab-ci just recently. Biggest problem was that the circleci runners lose the local docker cache, which meant that unnecessary large chunks of time were spent redoing docker container builds, slowing everything down in our workflow. Note that we run unit tests in docker containers, and to speed things up it would be useful to run unit tests in parallel on multiple separate machines, in addition to preserving the local docker cache on each runner machine.
> So assuming we fixed that, would you buy it (considering esp that GitLab CI exists and you already use GitLab)?
Yes but no, we already switched and we're on to other things. We reported the docker cache issues to you guys a looong time ago, and we get it- most of your customers are probably focusing on webapp unit testing, and probably not on building docker containers and then running unit tests in those containers. There's a lot of hammering to get each CI solution to work just right, but maybe we could switch back more easily if you guys made a gitlab-ci compatibility layer..... (big project, I know).
Oh also we have somewhat-malleable self-hosting requirements, but I mean for the right solution we've been able to forego self-hosting in the past.
That was true in the early days. Now we have toooooons of Docker customers, so this thing is right at the top of our TODO list (and would be done already if it wasnt architecturally hard).
Good timing. Recently installed Gitlab Community edition on DigitalOcean (one click install) and so far loving it.
Some issues:
- Does it have a default task management tool or we need to integrate a 3rd party ? Couldn't find it in the forums yet
- The UI is a bit clunky in terms of navigation. For example, being able to move from the homepage level to specific project back and forth is a bit confusing. Would love a re-design of UI.
EDIT:
Lot of feedback that I can give. So far:
- Make it easy to navigate between index page and specific groups/projects. May be on login to index, just show a dashboard with all groups/projects that I am part of. If Admin, then show me additional options like what you have in "Admin Area" menu. Here is one idea. Just show all menu options in the left sidebar and split it like:
- Home
- Groups
- Projects
- Project 1
- all menus that shows up for projects
- Admin Area
- Profile Settings
- Users
- Mail Settings
- User profile management is not that good for admins. For example, just yesterday one of my developers got locked out and I could not reset his access via the UI. I had to go in the config files to update the lockout timestamp.
- Also for new users, as admin I want the control to add them as verified user already. Currently I don't think that options is there in UI unless we fiddle with the code.
- For email driver, a simple form in UI will be nice to have. For example, if I want to use Mandrill, give me that option in the UI.
Bottomline is that even though we are developers, we don't want to change the .rb files for Gitlab and instead focus on an easy UI.
> Does it have a default task management tool or we need to integrate a 3rd party ? Couldn't find it in the forums yet
You can use Issues, which comes in every project and can be linked all throughout your GitLab instance. They also integrate with merge requests and can be used 'Kanban' style by using milestones.
See our own for GitLab's issues: https://gitlab.com/gitlab-org/gitlab-ce/issues
You can also integrate many of the popular systems, such as JIRA, Asana, Trello.
> The UI is a bit clunky in terms of navigation. For example, being able to move from the homepage level to specific project back and forth is a bit confusing. Would love a re-design of UI.
We're working very hard on this. The coming release will add more context to the menu and we're looking to improve it further both in terms of design, as well as UX.
It'd be great if you could share us your thoughts on how we can improve this.
Some proofreading issues related to the CI webpage (https://about.gitlab.com/gitlab-ci/).
). They're minor and easy to fix but I think they would help regarding sales:
-> Multi-platform since you can executes builds on Unix, Windows and OSX.
-> Stable because the GitLab CI is on a different machine that(n) the ones that perform builds.
Also the whole phrasing is a bit weird, I'd change it to:
Key feature: description.
The way it is now those phrases seem a little clunky and unnatural.
A totally separate issue, what are the limitations for the CI stuff? Build per day/per OS/whatever?
We're thinking about improving the navigation to / between projects and groups. We'll probably do something similar to your suggestion in the coming months.
We're trying to move as many things from gitlab.rb to the admin interface. We add more every release and intent to make (almost) everything available through the UI.
It's hard to compete against GitHub. I hope they will get some traction so we have an alternative to GitHub once it gets bought by MS (and becomes the next SourceForge).
Bitbucket is awesome. I'm using it for all non-essential repos that I have as a side/small clients projects. I'm paying for 5 private repos on GitHub and whenever I see that I don't use a repo that often I just move it to bitbucket ( I'm such a bastard customer - I know ).
Two examples, why I don't use BitBucket for big projects and essential clients :
1. Interface is not that good - e.g. makes it hard to manipulate issues.
2. Integrations with some CI is not as good as in GitHub.
Sometimes I end up on Bitbucket pages for a repo, and have a hard time locating how I can view the directory tree of the repo. I wouldn't call this "superior." It's not unfixable, but definitely not superior.
On an unrelated note, I gave up on GitLab last year because the landing page always showed recent commits instead of the readme, making it less welcoming to new users who just want to see what the project is about.
I'm glad to see they have changed this; navigating to a GitLab project now shows you the readme. Definitely going to give it a long hard look to see if I can switch again.
It really depends on the mindsets of users. My guess is that Github users tend to browse/read code in multiple repos more while Bitbucket users tend to work on their own private repos more. So it's logical that Github defaults to source tree while Bitbucket defaults to commit history.
I like the integration with Hipchat and the business model too. For small groups is a great place to start your work privately until is clean enough to make it public.
Nitpick: YouTube was 1.5 years old (founded in February 2005, deal finalized in November 2006)[0].
I just looked that up because I really thought YouTube had been around longer before Google acquired it. That's interesting to learn, so thanks for pointing that out.
Decided to switch to gitlab when I realized github refused to release their tools on Linux even though according to stackoverflow statistics Linux users make up over 20% of programmers, matching the number of OS X programmers.
It's unfortunate that they make a living off open source software created by a lead Linux developer but they act like Linux doesn't even exist.
Not a big deal though, the userbase on github is worse than facebook or 9gag.
Gitlab isn't much better than github when it comes to openess, but it seems to be the best alternative so far.
Nice. I really like GitLab. Made the move after GitHub started focusing on social justice instead of technology (plus I was tired of the hypocrisy of them making money from OS while keeping all their sources close), and I don't regret it.
The only thing, which doesn't really depend on you I assume :), is I wish GitLab was used more often as an authentication mechanism by other services. I don't know if GitLab is actually an OpenID provider or if it's just because it's not popular enough yet.
I apologize in advance for my short sighted question as I don't really know much about gitlab but my question is: does this mean anything for large file support in the community edition? I find it surprising there are no free solutions for large binary files other than perforce. Compared to most tools indie game devs use, perforce is a dinosaur.
We will not bring Git Annex [0] to the community edition.
However, we do accept merge requests for Git LFS support [1]. This means that if this is contributed to GitLab, it will be available in the Community Edition.
I find it surprising there are no free solutions for large binary
files other than perforce.
There's in fact lots of tooling in Mercurial to handle this precise problem, as well as gigantic repos. Mercurial's extensibility with these scaling problems, in fact, is why Facebook has chosen it. If you're not married to git, try checking out Facebook's Mercurial extensions.
I'm not sure you can fix it unfortunately but the number 1 thing I would miss is the community. I work with a lot of open source projects and the consistency and speed at which I can file bugs, fork repositories and pretty much do anything is really important, and the access to all the github users is a major part of that.
--
OK, this post was going to be some minor thoughts but turned into actual UX/dev feedback. Take from that what you will and keep in mind I haven't used Gitlab much at all.
What makes Github great:
- Ease of sharing a project. They got "social coding" 100% right.
- Filing an issue can take under 5 seconds.
- The UI is just great, slick, super responsive, everything updates without refreshing.
- Syntax highlighting is amazing. Syntax HL in diffs!
- Github profiles are great. For a lot of devs, github is a CV, keep that in mind.
- gh-pages/jekyll integration kicks ass.
- Referencing and auto-closing issues
- webhooks, IRC bots
--
Here are some killer features not present on Github that would make me very seriously consider switching some large projects:
- Mailing list support. Think Discourse/Groupserver/Google Groups -> A UI that doesn't suck, easy to enable for any project or organization, one click to subscribe/unsubscribe with your account
- Issue tracker's lack of features is both good and bad. Good for the speed at which issues are filed, but sometimes you really do need some extra features. (Marking as dupe; Making as "fixed" when an autocommit missed it; etc). Shouldn't go the bugzilla route and create meta-work, though.
- Proper support for mirroring repositories (two-way mirrors?)
- Improved IRC integration; eg. bots that watch over bug links / "Take a look at #1234" and spit out URLs and bug titles.
- Sign in with persona. :)
--
Where github simply falls short, and misc annoyances I have with it:
- Organizations/permissions. They said they're working on that.
- Gists could be improved and integrated with issues (cf. attachments). BTW I absolutely love gist, does GL have something like that?
- SSL support for gh-pages on custom domains is lacking.
- "Clean commit log" workflows aren't well supported. Rebasing messes with the commit ordering in PRs.
- Issue references in commit messages are great but when force-pushed several times, they spam the issues. No way to delete those messages.
- Comments on PRs disappearing. I haven't thought about proper ways to improve the PR review workflow on GH, but I know it can be improved.
- The contributions graph algorithm doesn't deal well with "mass push" outliers (see what I mean: https://github.com/jleclanche/)
- The "PRs are issues" legacy still shows itself, they moved away from it though.
- I constantly have to clean projects I forked for a single issue.
- Wikis are cool but kinda lackluster. No way to inter-link pages.
- It's closed source!
--
UX thoughts on gitlab.com, the site (about.gitlab.com):
- No way to see an actual repository, what Gitlab looks like. Github has a similar issue but at least has an "explore" link. I feel like the "features" screenshots should be on the homepage. There's plenty room if you squish/remove the corp/press logos and twitter spam.
- Video at the bottom is completely out of place. Looking at it, it has 55k views, that's really nothing. This contradicts my previous note but I didn't even notice it at first since it was so low.
- The page is fairly slow to load (~2 seconds). It's also huge. I really think there's just too much on it. Do you really need testimonies there?
- Love the link to that page being present, since it's the first question I'm asking myself. Dropping points on lack of graphics (examples/screenshots)
-> What caught my eye on that page: Attachments in issues. WIP protection is neat but gimmicky. Builtin CI kicks ass! I don't know what Innersourcing means. Maybe "unlimited p/p repositories" should be first? This is a long list, consider reordering some things.
I'm short on sleep, so feel free to follow up with me by email (it's listed on my profile) if you'd like.
Would appreciate better support for the Integration-Manager workflow described in http://git-scm.com/book/be/v2/Distributed-Git-Distributed-Wo.... It is possible to use this workflow with Bitbucket and GitHub but not with GitLab (possibly due to the differences in roles and permissions). I had already raised a feature request for this some time back. Would appreciate your thoughts on this.
Just saw that gitlab now offers free hosting, you only pay for support (only if you want it). Do enough people really pay for support in order to keep gitlab from going under? Free software is one thing, but free hosting? It just blows my mind how they can offer such a thing.
Hosting basically boils down to the fact that ~98% of your users will use a small portion of your resources. This is why hundreds - even thousands - of users are shoved onto a single shared server (all without ever having a problem). Considering disk and bandwidth is cheap - it's really inexpensive to host users. 2% of your users will attempt to use 50% or more of your resources - and those are the ones that you kick to the curb or arrange some sort of payment.
I used to do free web hosting and now have switch to just free source code hosting.
A perfect example of this is this story [1]. I'm sure a good 90% of people who sign up for the free slack service only use a small blip of usage.
It gives us the possibility to run GitLab on a very large scale. This helps us finding performance and scaling issues that otherwise would go unseen. In short, it allows us to make GitLab even better.
If this is really the case and your business model is aligned with this, there's nothing else to say, except "Congratulations!".
I didn't know that this can go so well for end-users in such a competitive environment. I hope I hear more arguments like these from other tech companies.
How do you call this model? I guess freemium doesn't match with how you make the benefit out of the website.
I guess it is freemium because most larger organizations at some point want to go on-premises (for security, legal, flexibility or other reasons) and opt for GitLab EE at that point.
You might wanna check out the twitter feed before jumping into their free hosting. Looks like they have had a lot of issues with connectivity/stability over the last few weeks at least.
Lots of places do it. Disk space relative to code size is extraordinarily cheap. Just look at the granddaddy, GMail. Google gave away 1 GB per user back in 2004 because they figured the ads would support it.
- I personally find it a little bit irritating that Github wants to promote "open-source/free-software", but haven't open sourced their own tools/product.
- I was disappointed by the way Github handled some internal problems
- I don't trust Github anymore; I want to be in control of my data.
I also just canceled my Github subscription and moved all of my private repos to a self-hosted GitLab. I did this because I was very unhappy with the politics that GitHub recently decided it wanted to push.
The funny thing though, having my private repos on my own server just FEELS nice. I have total control over my projects. I wasn't worried about anyone "snooping" on them but there's a subtle psychological change when you know your code is on your sever and no one other than you has admin access.
I moved for political reasons, but found the intangible benefits of being the "master of my domain" were a great unintended side-effect.
Don't sell this position short as a mere "political reason". Github has decided that rationality and critical thinking take a back seat. This is a vastly damaging attitude that hurts the world. Providing any encouragement to unclear thinking is a vile thing to do. This is far worse than environmentally unfriendly attitudes; it's far more important than even open source.
I agree that Github's positions are ultimately negative beyond the scope of the company and product itself.
Ironically the GitLab CEO has also injected politics where it didn't belong. Thus is the power of open source, even though I don't agree with GitLab Inc's politics, I can take the code base and host it myself.
I upvoted you only because people should know where companies like gitlab stand on these kinds of issues. I'm not agreeing or disagreeing what he did was right - but it is important to know about it.
I host my own free source code hosting service and I couldn't tell you what I would have done in his position.
This question isn't meant to spark a heated debate (I'm on the fence and could argue either way) - but I'm honestly curious on how you think it should have been handled? I honestly want to know if there is an action that benefits everyone.
Thank you for the upvote, I wish more people would engage in conversation vs. just downvote opinions they don't agree with.
I think the best course of action is to have a policy of:
"We don't delete repos unless required by law."
That would satisfy me as a potential customer.
I think commenting on Twitter and getting involved at all was probably a mistake unless they were going to stick with the above philosophy. All they did was call attention to the issue then delete the repo once everyone was watching.
The tweet seems like an honest mistake since I don't think they wanted to get involved with this controversy. They made it though and had to make some decision on what to do. I think they chose the most damaging option.
The staff doesn't have to personally endorse the opinions of their users and the repos they host. I wouldn't expect that of them, but they shouldn't delete repos they don't agree with.
> We don't delete repos unless explicitly requested by law enforcement or a DMCA takedown notice.
What you said could be interpreted as "well...this repo was technically breaking the law so that's why we deleted it" - I would rather say "I deleted it to cooperate with law enforcement". And the DMCA takedown policy is required to protect service providers in the event some idiot decides to upload copyrighted material - the RIAA/MPAA won't go after the service provider they will just ask them to take it down.
In case this is the policy it would mean we could not delete something like revenge porn ourselves, we would first have to wait for a takedown notice. I don't want to host content like that https://xkcd.com/1357/
That XKCD is one of the worst strawman arguments I've ever seen.
Freedom of Speech is not a law, and it's certainly not just a law found in one single document that applies to the United States. Here's what the United Nation's Universal Deceleration of Human Rights says:
> Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.
Not one word there refers to governments.
The true purpose of freedom of speech is to protect people from the consequences of their speech, because those consequences serve to silence unpopular ideas. Remember that historically unpopular ideas have included freedom of religion, African American civil rights, alternative sexualities, and even heliocentricism.
It depends on how you interpret the XKCD comic. It often gets used to argue "institutions have the moral right to block people if they have unpopular opinions", which goes against the spirit of free speech (even if it's not illegal). I don't know if that's it's original intent - it might just mean "You can't claim you have a constitutional right to swear at people on my forum".
A public forum (which GitLab isn't - it's a place for code more than politics) that doesn't allow civil discussion of on-topic ideas is arguably a bad thing.
From On Liberty, by JS Mill:
> If all mankind minus one, were of one opinion, and only one person were of the contrary opinion, mankind would be no more justified in silencing that one person, than he, if he had the power, would be justified in silencing mankind. Were an opinion a personal possession of no value except to the owner; if to be obstructed in the enjoyment of it were simply a private injury, it would make some difference whether the injury was inflicted only on a few persons or on many. But the peculiar evil of silencing the expression of an opinion is, that it is robbing the human race; posterity as well as the existing generation; those who dissent from the opinion, still more than those who hold it. If the opinion is right, they are deprived of the opportunity of exchanging error for truth: if wrong, they lose, what is almost as great a benefit, the clearer perception and livelier impression of truth, produced by its collision with error.
Of course, Mill assumed that most people are capable of rational thought, and would generally move towards a more correct view of the world when exposed to a marketplace of ideas. The internet doesn't always work like that. However, the alternative to "free speech" is echo chambers, which is probably worse.
But I don't see why GitLab has any real responsibility to allow stuff that's not code (or is just joke code) - it's not a really a marketplace of ideas, it's a place to share code. And given GitLab has a FOSS version, yes, people can get their own server.
Unless either of us can find Randall explaining his intent somewhere (and even then; death of the author probably applies - how sytse used the comic is equally important) all we can do is go by it's working. The comic doesn't say "The First Amendment", it says "Freedom of Speech".
I won't say that the average netizen shouting freedom of speech is educated on the philosophy of liberty or has read JS Mill (I haven't, I need too). But when they say freedom of speech about forums. Freedom of Speech is still a human right, not a clause in the USA constitution. I still think it's a strawman to respond by pointing the limits of the First Amendment.
> Of course, Mill assumed that most people are capable of rational thought, and would generally move towards a more correct view of the world when exposed to a marketplace of ideas. The internet doesn't always work like that. However, the alternative to "free speech" is echo chambers, which is probably worse.
On Liberty was written in 1859. It's an indisputable fact that in all forms of social justice - sexual equality, racial equality, LGBT rights, and far far more - things have been improved enormously during the last 66 years. If Mills ideas have either influenced or reflected the political philosophies of the those 66 years then clearly he's onto something.
Even the internet doesn't change much, human nature is still human nature. Besides, to pick a date, the internet has only been influential since September 1993. Social justice has mostly gotten better since 1993 even if online discourse has gotten worse. It's premature to say we the world is too different to go by On Liberty.
After 66 years of liberty bringing progress we should only attempt to replace liberal ideas with the utmost care, thought and deliberation. And when I see people arguing to limit freedom of speech, I do not see that care and deliberation; if I did a comic saying that Freedom of Speech was merely a clause in one country's legal code would never have gotten popular.
> But I don't see why GitLab has any real responsibility to allow stuff that's not code (or is just joke code) - it's not a really a marketplace of ideas, it's a place to share code.
If they had a clearly written rule saying only code is aloud, or only code and documentation relating to code is aloud then that would be fine.
However once GitLab starts judging repositories based on the ideas they contain and deleting legal repositories they dislike then they have crossed the line.
If you are legally required to take something down it is kind of different from when you freely choose to do so because you find the content objectionable on ideological grounds. In this case you decided to act against the principles of free speech and network neutrality of your own free will.
Some for instance (GitHub, BitBucket, Google Code) also decided to remove the satirical "C+=" repo from their service, you didn't: https://gitlab.com/femsf/c-plus-equality
For interested parties, there is actually a server that has existed for a while, but this is mostly about the choices you make as a company in the wake of GitHub deleting repos over the use of the word "retarded" and employing an intentionally discriminatory Code of Conduct: https://gitgud.io/gamergate/gamergateop/tree/master
Nobody is arguing this isn't your right as a company, they are just questioning your judgment and reason and if their projects are safe with a company that will remove something that doesn't intellectually agree with the political stance of its CEO.
Most of them don't want to deal with the volatility of a professional environment where someone just has to be "offended" and their work could be arbitrarily pulled.
Completely agree with this. If Gitlab is not willing to have a clear policy regarding takedowns I will never be a customer. I paid for Github service for years and pulled my stuff once they decided to get political.
I really wanted to like Gitlab but a "case-by-case" policy basically means "whatever we feel like," and that is not an acceptable standard for something as important as my work.
> In case this is the policy it would mean we could not delete something like revenge porn ourselves
I could argue either way (I'm a bit of a philosopher that way...). It all depends on how you want to run your service. Do you want a reddit-free-for-all-wild-west or do you want to keep it PG-13?
Either way - it should be clearly defined where you stand and what you allow/don't allow. Making it a guessing game isn't going to win you any fans.
We make decisions on a case by case basis and people can judge for themselves if they think it is reasonable. Clearly defining where you stand is very hard, and we don't think we'll do a good job at it. Giving a definition and then backtracking won't win us any fans either. Anyway, it will be more PG-13 than the old Reddit.
We'll never delete data, we will make the repositories private. You will have to move your public project elsewhere. For significant projects we're open to making it public when you've replaced the repo with one announcing the new location.
That's really disappointing and something I'll be watching for a proper resolution. Gitlab appears to be getting involved with how people seek anonymity on Twitter, which is just odd.
> I personally find it a little bit irritating that Github wants to promote "open-source/free-software", but haven't open sourced their own tools/product.
I set up gitlab internally a couple years ago and it has been a pleasure. One big thing I fight is we have a lot of micro services that we want to have the same label set for and would like to manage against the same milestones. It would be really nice if label sets and milestones could be created for a group.
Feel free to contribute that feature. I would love to create a milestone for all projects in a group in one go. Please be aware that if you name the project milestones the same you can use them to aggregate issues across multiple project in one view.
How does the licensing works? Can anyone explain me? [0]
> This software and associated documentation files (the "Software") can only be
used with a valid GitLab subscription for the correct number of users. You are
free to modify this Software and publish patches. It is forbidden to copy,
merge, publish, distribute, sublicense, and/or sell copies of the Software.
Isn't the third line contradicting with the fourth or have I misunderstood?
A patch - literally a file generated by "diff" - only incidentally contains the original code, mostly your new functions and modifications. So you can't distrbute a patched version of the software, only the patch itself.
As a Gitlab CE user and part of a large company using Gerrit for code reviews I am really surprised that Gitlab does not try to emulate a bit more the various enterprise grade Gerrit features available such as full side-by-side diffs with key shortcuts, review history to easily see what changed since the last time you reviewed the merge request (even with rebased commits), +1/+2 rules, custom plugins available... Etc.
I know that Gitlab EE has some features like the merge request rebase, but I don't know how a large company using gerrit could be convinced to switch to reviews in Gitlab
Anyway, I'm sure that there are still things missing and you are very welcome to add them to CE or EE. We had large companies switch from Gerrit but we hope to keep adding features that people currently miss.
We've been enjoying GitLab for quite some time now, but I have to say with every new release they always seem to break something critical for us, there seems to be far too many regressions and many of them are not communicated evening with their paying customers - for example the latest one that's been causing us grief: https://gitlab.com/gitlab-org/gitlab-ce/issues/1974
We're actively working on finding a solution for this. We understand this is not a nice development for many of our users.
We do not want to inadvertently break the workflow / remove essential features without informing our customers in advance. And we will always work hard to ensure that if that does happen, we find a good solution for all parties.
If you do find that this is the case for you, as a customer of GitLab, please never hesitate to contact us through our support channels.
As well as logging that ticket publicly in case anyone had a contribution to fix the issue gitlab was contacted through the paid subscribers channel and their response was that they would follow it up on that public issue. I don't have an issue with that so let's wait and see A) what the fix is and more importantly B) what lessons were learnt from the regression.
Coincidentally, I just installed GitLab to try it out for our small team to replace BitBucket + Jira. And while its more than capable filling Bitbucket shoes the issues subsystem is probably worse than github's and nowhere near flexible as jira.
Most notably: Missing more sophisticated workflows. Search for issues using multiple labels. Search for issues across multiple projects.
We would also love to be able to do simple time tracking against issues.
Is there no reasonably priced product out there that would fit our (rather simple) needs?
I agree, we're using gitlab too and the only problem is the lack of ticket system feature (due date/alert reminder, multiple people assignment, advanced filters, simple markdown text editor for client, time tracking, edit default label for all project,...) otherwise we hightly recommend it.
Thanks, we're looking some of these but we want to keep it light and easy to use at the same time. Please be aware that some scrum tools also integrate with GitLab https://about.gitlab.com/applications/#scrum-boards
Still using Redmine for self-hosting here, Gitlab is too heavy for small teams. Thought about trying Phabricator but then its various components with strange names stopped me from trying, plus it seems clunky for small team too.
I recommend giving Phabricator a try. After evaluating several different tools we ultimately went for Phabricator. When I initially looked at it in ~2012 I was put off for similar reasons:
1. References to pokemon on main pages
2. Confusing names for features
3. Written in PHP (this was an initial bias from my prior experience with the language and belief that such a language wouldn't be used to maintain a large-scale application).
These three points led me to believe that Phabricator was not a first-party application but just PHP glue tying together other open source applications. With this in mind, along with the pokemon, I wrote it off as some highschool/college project and turned my attention elsewhere.
I took a fresh look at it in 2014 and realized several of these misconceptions. The developers of Phab tend to be light-hearted and embrace some humor in development. This has proven to be valuable in sustaining good-natured development teams and keeping code-criticisms well-intentioned. They also have a "serious" setting which tones down some of the language in the application itself.
The feature names can be confusing, which is a valid criticism though after a week or so it doesn't tend to interfere with work. The most difficulty in adopting Phabricator has been getting developers to understand the different development workflow to utilize the code review. Our team sizes range from ~3 to ~8 and haven't had any major problems.
They have an IRC channel which is usually pretty active, and I'm sure any questions or concerns you have can be brought up there.
We've been using it since ~Febuary 2015 and it's been a terrific addition to our development.
1 core works for under 100 users but the responsiveness might suffer
2 cores is the recommended number of cores and supports up to 100 users
4 cores supports about 1,000 users
8 cores supports up to 10,000 users
Memory
512MB is too little memory, GitLab will be very slow and you will need 250MB of swap
768MB is the minimal memory size but we advise against this
1GB supports up to 100 users (with individual repositories under 250MB, otherwise git memory usage necessitates using swap space)
2GB is the recommended memory size and supports up to 1,000 users
4GB supports up to 10,000 users
We use Redmine for ticket / issue / task tracking as well as rough timesheeting, and we use gitlab and gitlab CI along side it. I quite like how quick Redmine is and how it just gets out of your way. We find gitlab to be pretty quick however upgrades are painful due to regular bugs / regressions.
Ideally I'd like to see something like Taiga and Gogs together which I think would absolutely fly.
Since gitlab closed gitorious.org, I've switched to serving all of my repos as static files generated from git2html, and accepting patches by email. Once burned...
Just for your information, we had a 'one-click' import from Gitorious to GitLab.com. It will come online again after the internet archive work is done.
"Sensitive issues, such as security issues with GitLab, will still be handled internally. We’ll create tracking issues for these on the public issue trackers that don’t contain exploitable information."
The article is about the issues that will almost all be open. The complete quote you refer to is is "In fact, even our proprietary version of GitLab, GitLab Enterprise Edition, has a publicly viewable source code.". Can we be any more clear it is proprietary? We think it is notable that even the source code and issues of out proprietary edition are publicly viewable.
Perhaps it's just me, but when they said the enterprise edition was "publicly viewable source code", I assumed they just meant it was "publicly viewable", with no further rights implied.
I don't think they're really openwashing here, and the article was pretty clear to me. Besides, the community edition and CI code are both true open source.
Isn't there a slight problem with having the EE code publicly viewable?
What I mean by this is, what's stopping someone from taking code from the EE, modifying it, and including it in the CE?
On the flip side, what if a feature released to CE is too similar to code in EE, even if the author of the patch never read the EE code for inspiration? Would GitLab be within their rights to stop it?
With these issues in mind, it makes more sense to me to have the EE code available by request only.
That's not the definition of "open source", that's the definition of "free software". As you can see by this very article, "open" and "free" are not the same.
The only difference is their argument. Free software uses ethical arguments, open source denies ethics altogether and uses consequentialist arguments related to business value and technical superiority (which are becoming increasingly criticized).
Yes. Because of the ethical standpoint, free software inherently opposes DRM, Tivoization, "trusted computing" and software patents, whereas open source in general has no intrinsic view on them.
It's far from irrelevant. Free software advocates are clear: proprietary software is unacceptable, in any form, for any reason.
It has nothing to do with being ungrateful. We express our appreciation when software is liberated, or when developers/companies are working toward it. But it does not change the fundamental philosophy.
Irrelevant to you perhaps. But please don't tell people to shut up. What you say can also be regarded as whining btw - you mean good, I think, but this just won't help one bit. Better to participate constructively than to express this type of annoyance.
But that's the enterprise license, not the community license.
When they say "In fact, even our proprietary version of GitLab, GitLab Enterprise Edition, has a publicly viewable source code", I don't think they're implying it's open source.
> You are free to modify this Software and publish patches.
> It is forbidden to copy, merge, publish, distribute, sublicense, and/or sell copies of the Software.
You might want to get a lawyer on the phone - because that seems contradicting to me. This is why you should stick with open source licenses that have been vetted by a team of lawyers already. You should check out the AGPL license.
It doesn't matter which product it was for - it still seems contradictory. It says I can distribute patches but then it says I can't.
I wasn't joking when telling you that you should get a lawyer on the phone. I've seen a number of people try to write their own software license - and fail miserably. It really has me kind of worried that your response wasn't "we did consult with a lawyer when creating that license".
In what way does it seem contradictory? It seems to allow one to write and publish patches, while disallowing the redistribution/resale of the original code.
Distributing a patch would require distributing parts of the original code (the patch file will include lines of original and changed code) - which the latter is not allowed per the license.
I'm not saying that gitlab would go after you for just distributing a patch - but if anyone gobbled up gitlab coughOraclecough I'm sure they would summon a swarm of lawyers at your doorstep.
If you have any suggestions how to word this better I'm open to them. We did have a lawyer look at this. It is like sampling, you can use a bit but you can't use it all.
Well for starters most licenses will define the meaning of the terms in question. You should define exactly what is a patch file (such as format and what it contains). Potentially a patch file could include whole files.
Here is a hypothetical situation: what would you say if I included your entire program in a patch file. If you are saying patch files that contain your code are ok to distribute - but I'm sure you are going to say that's not ok. But why not? Your license says I can distribute patches - it just so happens this patch file contains every file in your program.
The question here is how much patch file is too much? Is there a limit?
A better idea would be to require your sign off on every patch. Or only allow patch files to be uploaded to a forum that is accessible to enterprise only customers (vBulletin has a similar setup).
I don't think most people will consider an entire program a patch.
Having us sign off on every patch defeats the intent of the clause. The intent is to give our customers a way to submit merge requests on https://gitlab.com/gitlab-org/gitlab-ee/merge_requests and to be able to comment on for example Stack Overflow with fixes they made so other customers can learn from that. We don't want to slow down that process.
The GPL is one that I know that spells it out [1]:
> This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
> This allows the judge to interpret them according to their common meaning
Uhhh....you mean the same legal system that claimed that Ron Rivest et al. were not the original inventors of the RSA algorithm? [2]
I don't know who is counseling you on legal matters but I strongly believe you should define anything that can be ambiguous.
[3] > DO define all technical terms.
[3] > DON'T assume the other party defines terms the way you do. If there is any doubt, include a definition in the contract.
[3] > DON'T accept the other party's oral explanation of a confusing term. Include everything in writing.
[3] > I don't think most people will consider an entire program a patch.
Why not? It can easily be done [4]. Example: here is a patch file to upgrade from CE to EE.
Just as an aside - we seem to be crossing paths a lot on here...
I think you should just hire me as your PR and/or developer guy ;). It's always good to have a guy with a different perspective who thinks and plays outside the box. I mean inside the box is so boring....
> I do wonder how would you define the patch file?
Something like....
> A patch file contains the modified file name, author of the change, date, hash with snippets of content recording the changes. A patch file cannot contain enough information to reconstruct the software in whole or modify the CE to include copyrighted features in the EE edition. The author must not knowingly introduce backdoors, exploits, or other code that introduces malicious intent. If the author is identified their gitlab EE license will be revoked irrevocably and permanently and requested to halt any use of gitlab EE.
(However - a patch may still introduce features from the EE edition that were written with original code)
> A patch may be released under whatever license or agreements the author wants without the requirement for permission from Gitlab if it satisfies the previous conditions.
It might be good to add a clause:
> By applying a third party patch you agree to not hold Gitlab liable for any damages or misconfigurations that might happen by applying the patch. You acknowledge by applying a third party patch that it may fix your problem, introduce a new problem, or open a tear in the space-time continuum.
I'm sure you get the idea. I'm tired and I just watched an episode of Doctor Who - so I had to include something related to time :).
Thanks! We're hiring https://about.gitlab.com/jobs/ Our lawyer will also study this comment. I'm sure he'll discourage us from offering guaranties against tears in the space-time continuum. Have a good night.
Announcement itself is fine. The way you contrast "open" with "proprietary" is a bit jarring. It should be free versus proprietary, but if you find that undesirable, then just go with open/closed.
EDIT: Quite predictably, I got downvoted for asking people to use proper terminology and for promoting free software.
People just hate when you correct their semantics, don't take it personally. Many people also don't know the difference between free and open. Here's a popular article by RMS which explains the difference: http://www.gnu.org/philosophy/open-source-misses-the-point.e...
That ship has sailed. Today, "open source" means "free" in Stallman's terminology. Asking people to use nonstandard terminology in order to promote a particular viewpoint is not reasonable.
Things that almost make me want to switch back to GitHub:
- GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.
- GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.
- GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.
- CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.
- Typography could be improved. When you're looking at the issues page all day, this is quite noticeable.
- Slack integration is not great; it dumps links to "GitLab Enterprise Edition" instead of useful commit/changeset stuff like GitHub does.
If the community/GitLab can focus on putting on some of the design polish and service integration polish that GitHub has, GitLab would be a total winner for us, long-term.