Almost Everything We Do Will Be Open(about.gitlab.com)
about.gitlab.com
Almost Everything We Do Will Be Open
https://about.gitlab.com/2015/08/03/almost-everything-we-do-is-now-open
196 comments
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.
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.
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.
Where do you feel I injected politics where it didn't belong? I want to understand where you're coming from.
https://archive.is/d1Sd7
You should not have got involved in this as a company. I want to support you and do self-host GitLab but because of this I won't be a customer.
You should not have got involved in this as a company. I want to support you and do self-host GitLab but because of this I won't be a customer.
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.
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.
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.
Would you be ok with a policy of:
> 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.
> 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.
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.
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.
That's why I don't want to do business with you. We already have a legal system to judge these things. GitLab doesn't need to take that on.
Also, the GG repo had nothing to do with revenge porn.
My initial post was promoting GitLab. I'm not sure I'm comfortable doing that anymore.
Also, the GG repo had nothing to do with revenge porn.
My initial post was promoting GitLab. I'm not sure I'm comfortable doing that anymore.
The legal system is not instant nor perfect.
> 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.
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 don't delete repos unless explicitly requested by law enforcement or a DMCA takedown notice.
Yes, this policy sounds great to me.
Yes, this policy sounds great to me.
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.
Thanks for posting the link to the Gamergate conversation, I understand where you are coming from now.
So you stand by your decision to remove a repo for political reasons?
> 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.
They have 100+ open-source repos: https://github.com/github They also contribute a lot back to Git.
They have 100+ open-source repos: https://github.com/github They also contribute a lot back to Git.
I take that back then, I was misinformed
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?
[0] - https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE
> 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?
[0] - https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE
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.
Exactly, that is how I meant that.
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
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
We would love to add features like that. We have side-by-side diffs and shortcuts, but maybe not what you want. New commits are shown in the discussion (doesn't work with rebasing). You can have approvers for merge requests https://about.gitlab.com/2015/06/16/feature-highlight-approv... and we support project services http://doc.gitlab.com/ce/integration/README.html
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.
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.
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.
If only this post was written by GitHub.
Everything should be open. Its almost immoral to sell software nowadays. No wonder so many people are flying to mobile...
As always, if anyone has any questions, we're here.
Well done guys. I've been thinking about completely open models for a while now; we have a similar model at work (on FOSS as well).
I'm a hardcore Github fan but I'm really impressed with what you've all been doing. The more I see your work, the more I want to switch.
I'm a hardcore Github fan but I'm really impressed with what you've all been doing. The more I see your work, the more I want to switch.
That's great to hear.
You can give it a try / use it for free at GitLab.com (public and private).
We would love to hear what hardcore GitHub fans like you miss in GitLab. We want to be better.
You can give it a try / use it for free at GitLab.com (public and private).
We would love to hear what hardcore GitHub fans like you miss in GitLab. We want to be better.
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?
- Top of the page is overall excellent.
https://about.gitlab.com/better-than-github/
- 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.
--
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?
- Top of the page is overall excellent.
https://about.gitlab.com/better-than-github/
- 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.
This is amazing, thank you!
I'll start working through it and see what we can do. I'll follow up by email!
I'll start working through it and see what we can do. I'll follow up by email!
My pleasure, I hope it helps. I edited a couple of bits in.
> SSL support for gh-pages on custom domains is lacking
How could they do that? You’re responsible for your own domain, you have to buy an SSL certificate by yourself.
How could they do that? You’re responsible for your own domain, you have to buy an SSL certificate by yourself.
Just wait until November. (https://letsencrypt.org/)
It's not supported.
It's so encouraging to see companies go open like this – thanks!
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.
Can you maybe link to the feature request?
Are there any plans with the CI to allow me to download the artifacts from a finished CI task?
It would be nice at times to download old builds at certain commits that the CI server had built in the past.
It would be nice at times to download old builds at certain commits that the CI server had built in the past.
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.
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.
What about security issues?
Those will be in public too? Or you should contact by email when you have a security issue.
Those will be in public too? Or you should contact by email when you have a security issue.
"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."
For sensitive issues you can email us at support at gitlab dot com.
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).
Is bitbucket considered not a competitor? I've found it quite suitable for anything github does, though I'm at max a 5 person team.
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.
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.
BitBucket is far superior to GitHub. It's not even a question.
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.
Precisely the one reason I can't bother to use it for real: I'd like the source tree to be the default view.
Settings -> Repository details -> Landing page -> Source
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.
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.
Awesome, hope you like what you find.
Sure, but that should be the default setting, even if it can be changed.
> Sure, but that should be the default setting, even if it can be changed.
That's a strong statement... I prefer bitbucket default view actually. The fact I can see the latest commits right at the start is very useful to me.
That's a strong statement... I prefer bitbucket default view actually. The fact I can see the latest commits right at the start is very useful to me.
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.
What? :)
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.
Github has a lot of social features, but as a git hosting service, Bitbucket is as good as Github. And Bitbucket has free private repos.
Why would Microsoft buy github? They have their own.
Why did Google buy YouTube when they have Google Video?
YouTube was <1 year old when it was bought; GitHub is 7 years old.
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.
[0] https://en.wikipedia.org/wiki/YouTube
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.
[0] https://en.wikipedia.org/wiki/YouTube
For the same reason they're using GitHub to host all of their new open source initiatives.
Can't beat em', eat em'.
So if customers want to contribute to fixes for issues they raise, is there a an easy way for them to do that without revealing who they are?
Yes. All our customers have a direct line to our support. We ask them to raise issues there, not on the public issue tracker.
This article uses a bit of openwashing to make "publicly viewable source code" seem "open". It's not. It's proprietary.
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.
Your wording is fine. Parent is being far too cynical.
Thanks, I don't want to be seen as openwashing. Open core is a tricky thing and we want to find a good balance.
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.
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.
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.
> what's stopping someone from taking code from the EE, modifying it, and including it in the CE?
1. Copyright law.
2. For corporations it's probably more cost effective to pay a subscription than maintain a fork.
1. Copyright law.
2. For corporations it's probably more cost effective to pay a subscription than maintain a fork.
1. It's not necessarily easy to prove that the new code has its origin in the existing code.
2. For some corporations, yes, for potential competitors, no. Furthermore, I wasn't talking about a fork, I was talking about committing to CE.
2. For some corporations, yes, for potential competitors, no. Furthermore, I wasn't talking about a fork, I was talking about committing to CE.
For those marking me down, say why you disagree. At the moment I'm under the impression I hit a raw nerve, I don't think I'm in the wrong.
It is, we don't intent to be vague about this. I hadn't heard of the term openwashing, but I understand the criticism.
See also our license for our proprietary GitLab Enterprise Edition: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE
And the license for our open source GitLab Community Edition (MIT Expat): https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE
See also our license for our proprietary GitLab Enterprise Edition: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE
And the license for our open source GitLab Community Edition (MIT Expat): https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE
> It is forbidden to copy,
merge, publish, distribute, sublicense, and/or sell copies of the Software.
Well, you are. Let me read to you the definition of Open Source:
> Open source software is software that can be freely used, changed, and shared (in modified or unmodified form) by anyone.
> Open source software is software that can be freely used, changed, and shared (in modified or unmodified form) by anyone.
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.
http://www.gnu.org/philosophy/open-source-misses-the-point.e...
http://www.gnu.org/philosophy/open-source-misses-the-point.e...
They are: http://opensource.org/osd
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).
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.
I disagree. Would it be accurate to call The GitLab Enterprise Edition "open source"? If not, what would you call it?
> what would you call it?
I've heard the term "shared source" which is pretty self explanatory - you can view the source but it's not open/free.
I've heard the term "shared source" which is pretty self explanatory - you can view the source but it's not open/free.
It's not open source because "open source" is a term with an established definition by the OSI that GitLab Enterprise does not meet.
We call it proprietary to prevent any confusion.
Great, the age-old debate on what is and isn't open source vs free software. We really needed that in here.
Y'all need to stop whining about the irrelevant when companies like these are doing literally everything else right. It's pretty damn ungrateful.
Y'all need to stop whining about the irrelevant when companies like these are doing literally everything else right. It's pretty damn ungrateful.
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.
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.
Except of course CE is free software, and this all stems from GP misinterpreting a very-well-worded source available note.
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.
It truly is distressing how programmers whose livelihood depends on free software (or "open source", if you prefer) are often so ignorant about it.
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.
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.
Indeed, GitLab EE is proprietary, GitLab CE is open source (MIT Expat)
Their community edition is open source, no?
[deleted]
> 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 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.
As KingMob pointed out, I linked to our proprietary license of GitLab Enterprise Edition.
GitLab Community Edition is licensed under the MIT Expat license: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE
GitLab Community Edition is licensed under the MIT Expat license: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/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".
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.
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).
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).
In contracts most terms are not defined. This allows the judge to interpret them according to their common meaning, for example https://en.wikipedia.org/wiki/Patch_(computing)
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.
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.
> In contracts most terms are not defined.
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.
[1] http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC...
[2] https://gigaom.com/2013/11/26/troll-wins-newegg-encryption-p...
[3] http://smallbusiness.findlaw.com/business-contracts-forms/do...
[4] http://stackoverflow.com/a/9982282/195722
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.
[1] http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC...
[2] https://gigaom.com/2013/11/26/troll-wins-newegg-encryption-p...
[3] http://smallbusiness.findlaw.com/business-contracts-forms/do...
[4] http://stackoverflow.com/a/9982282/195722
You have good points, I'll have a lawyer look at this again.
I do wonder how would you define the patch file? How would you prevent people splitting up the changeset into multiple patch files?
I hope the intent of our license is clear. Most people and organizations want to do the right thing.
I do wonder how would you define the patch file? How would you prevent people splitting up the changeset into multiple patch files?
I hope the intent of our license is clear. Most people and organizations want to do the right thing.
He linked to the enterprise license, not the community license. The CE license is open source, the EE is not.
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.
[0]: http://doc.gitlab.com/ee/workflow/git_annex.html
[1]: http://feedback.gitlab.com/forums/176466-general/suggestions...
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.
[0]: http://doc.gitlab.com/ee/workflow/git_annex.html
[1]: http://feedback.gitlab.com/forums/176466-general/suggestions...
I find it surprising there are no free solutions for large binary
files other than perforce.
What web interface supports LargeFiles?
Mercurial has had support for large binary files using the 'largefiles' extension for several years now.
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.
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.
> 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.
They do contribute back; they’ve done plenty of contributions to Git. Also, GitHub tools are really useless when you’re used to vanilla git.
They do contribute back; they’ve done plenty of contributions to Git. Also, GitHub tools are really useless when you’re used to vanilla git.
Which tools are you talking about?
Git.
Git is widely available, even on github: https://github.com/git/git
apt-get install git
pacman -Sy git
emerge --ask dev-vcs/git
yum install git> Not a big deal though, the userbase on github is worse than facebook or 9gag.
Found the grumpy linux user ;)
Found the grumpy linux user ;)
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.
> Free software is one thing, but free hosting?
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.
[1] http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...
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.
[1] http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...
We do not make substantial money with GitLab.com.
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.
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 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.
https://twitter.com/gitlabstatus
https://twitter.com/gitlabstatus
We're seeing a lot of growth on GitLab.com. We just quadrupled the amount of instances running GitLab.com and are working hard on improving stability.
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.
Github does exactly the same with Github Pages.
Diskspace and bandwidth are relatively cheap!
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.
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.
Not to be rude, but isn't their software open source? Can't you try and patch it yourself?
If I've read his post correctly he's a paying customer. Surely that has to count for something :)
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.
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.
Great! Anything you miss, coming from GitHub?
Not really for now.
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.
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.
Great!
GitLab can be an OAuth provider since version 7.7 [0]. I think it takes a while for this to be adopted by other services.
Any advice or help improving this situation is welcome.
[0]: https://about.gitlab.com/2015/01/22/gitlab-7-7-and-ci-5-4-re...
GitLab can be an OAuth provider since version 7.7 [0]. I think it takes a while for this to be adopted by other services.
Any advice or help improving this situation is welcome.
[0]: https://about.gitlab.com/2015/01/22/gitlab-7-7-and-ci-5-4-re...
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?
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
After my experiences with Jira, "nowhere near as flexible as Jira" sounds like high praise.
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:
- 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.
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
- 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.
Happy to hear!
> 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.
> 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?
-> 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?
Thanks, fixed here: https://gitlab.com/gitlab-com/www-gitlab-com/commit/a70f6693...
Regarding limitations: at this point there are no limitations.
Regarding limitations: at this point there are no limitations.
see my edited response.
Thanks, that's some very nice feedback.
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.
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.
For task management you can use the build in issues and tools that integrate with that https://about.gitlab.com/applications/#scrum-boards
Your navigation remarks are spot on and inspired me to make this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/2225
Doesn't the lockout expire at some point? I agree it would be nice to reset from the UI.
Mmm, I thought that if an admin added a user they didn't have to verify their email.
Do you mean something like project services? http://doc.gitlab.com/ce/integration/README.html
I agree that your shouldn't change .rb files. Please contribute any improvements you make so we can include them.
Your navigation remarks are spot on and inspired me to make this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/2225
Doesn't the lockout expire at some point? I agree it would be nice to reset from the UI.
Mmm, I thought that if an admin added a user they didn't have to verify their email.
Do you mean something like project services? http://doc.gitlab.com/ce/integration/README.html
I agree that your shouldn't change .rb files. Please contribute any improvements you make so we can include them.
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. 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.
What makes you feel GitLab is too heavy for small teams?
In terms of load, it can run on a Raspberry Pi.
In terms of load, it can run on a Raspberry Pi.
CPU
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
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 usersIt runs on a RPi2 https://about.gitlab.com/2015/04/21/gitlab-on-raspberry-pi-2...
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.
Ideally I'd like to see something like Taiga and Gogs together which I think would absolutely fly.
Redmine works well with git too, the only thing missing for me is a nice code-review plugin.
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.
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.
Thanks for the feedback, we really appreciate it!
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.
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.
> 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.
typefaces are cached by the browser. Done properly, you should see zero impact on page load past the first load.
+1
Also worth checking out: https://www.filamentgroup.com/lab/font-events.html
Also worth checking out: https://www.filamentgroup.com/lab/font-events.html
> 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.
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 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.
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.
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).
In general we recommend to run tests all the time. Machines are cheap compared to developers and you can add as many runners as you want.
What you can also do is use project or system hooks to trigger CI via the new build API that will be available on August 22.
Another option is to skip builds, you can just add [skip ci] to your commit message, and next build will be skipped.
What you can also do is use project or system hooks to trigger CI via the new build API that will be available on August 22.
Another option is to skip builds, you can just add [skip ci] to your commit message, and next build will be skipped.
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.
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.
Yeah, fixing that is a very high priority for us atm.
So assuming we fixed that, would you buy it (considering esp that GitLab CI exists and you already use GitLab)?
So assuming we fixed that, would you buy it (considering esp that GitLab CI exists and you already use GitLab)?
> 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.
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).
> Even BitBucket looks better.
Slight tangent: I think Bitbucket looks nicer than GitHub in almost every way.
Slight tangent: I think Bitbucket looks nicer than GitHub in almost every way.
If you are interested in knowing why:
- 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.