With VideoLAN, we're not on github, but I believe we fit the 'large open source project' description. We host VLC, FFmpeg, x264 and quite a few related libraries.
For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure.
And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting the change.
The first part is the groups and subgroups: it seems incredibly difficult to give sub-groups access to repos (like a team for iOS, one for Android, one for libVLC... but all are under the "videolan/" group). It seems there is a way with the EE, but not in the CE; and the current idea for the CE is to have sub-projects, which is not good, because it will make our URLs way more complex than needed.
The second part is the bugtracker/issues tracker. We use trac for VLC, and we want to leave it for something better; but gitlab issues is way too limited, even when using the templates. Especially, it seems to be impossible to add custom searchable fields (like "platforms", "priority" or "modules") which are very very useful to do queries. Also, there is no way to do custom queries and store them ("I want all the bugs for Windows, which are related to the interface modules").
If I remember correctly, this second part was also a complaint in the open letter to github.
Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them.
PS: can we have custom landing pages and custom logo in the CE version? :D :D
2. You can add custom labels on issues and the searches can be stored in urls that you can bookmark and use in links. You might have considered this already and need more functionality. Maybe it is best to discuss this in an issue so I created https://gitlab.com/gitlab-org/gitlab-ce/issues/10712 Please add there what you need in addition to the labels functionality. We addressed the long list of items raised in the original Google Doc letter below the signatures in https://gitlab.com/gitlab-org/gitlab-ce/issues/8938#improvem... The first item under improvements details our reponse to that question.
3. In GitLab you can give each user a fixed number of new projects. That should prevent people from storing a excessive amount of repo's. But feel free to make a feature request to limit people to only forks. As other replies have indicated that still allows people to work around it but at least the intention will be clear.
4. A custom landing page and logo is an EE feature http://doc.gitlab.com/ee/customization/branded_login_page.ht... We think this is more relevant for larger organizations so we're comfortable for having it as EE only at the moment. As mentioned under 1. we're open to offering you (and other open source projects considering self-hosting) a lifetime EE license.
I'll be in the comments today (just woke up in SF). You and any other open source project can always reach me at sytse@ company domain to get assistance or claim the EE license.
The whole idea of VideoLAN infrastructure migration from gitweb/trac/etc to gitlab and not to github was to use and promote free and open-source software.
Using closed-source software there is out of question, really.
This is really a problem I think. Maybe GitLab could reconsider to adopt a licensing model[1] for the Enterprise Edition that would make it more Free Software friendly?
[1] I.e. a licensing model based on GPL and selling services that Red Hat uses for RHEL, instead of a licensing model like they, and a minority of the "open source" companies, use.
When we introduced the Enterprise Edition we had it under MIT license. This caused much confusion with our customers. Maybe the situation is better now with companies like Hortonworks educating the market. But unlike others we want to make our open source edition as simple to install and maintain as the paid version.
My understanding from taking a Red Hat sysadmin course is that what you get from a RHEL subscription is firstly access to their repos from which to download updates and additional packages. The other, perhaps bigger, portion of a RHEL subscription is the support; I think they will answer the phone and provide you fixes for any bugs in RHEL-provided software relatively quickly. This is nice for companies, for whom uptime and stability are often superior to most other concerns, like staying close in feature parity to upstream.
Note that the accepted answer there is wrong, as it ignores the fact that the question asker wanted to distribute virtual machines containing the software, which is a violation of the GPL. The currently second answer by h22 is correct.
"This software and associated documentation files (the "Software") may only be
used if you (and any entity that you represent) have agreed to, and are in
compliance with, the GitLab Subscription Terms of Service, available at
https://about.gitlab.com/terms/#subscription (the “EE Terms”), and otherwise
have a valid GitLab Enterprise Edition subscription for the correct number of
user seats."
Thanks a lot for the answer and the proposal. But we do not want to have anything critical that is not open source. We try to promote OpenSource, so using non-open-source software is hard to do.
1. Thanks, but see above :)
2. As I said, custom labels are way too limited, as people on the open-letter-to-github said, so I will comment on the issue.
Thanks, I get that you don't want to be on proprietary code. I'm look forward to your email. And we're open to discussing open sourcing features if that is needed.
I don't know if that would apply to GitLab too, but maybe consider switching from the CE / EE model to just one "product" and a free for non-commercial model? Like e.g. http://3t.io/mongochef/download/ does it? I like that model way more than a feature-reduced version.
We considered that but we value having a completely open source version for all projects more. For more information about how we see the difference between CE and EE please see https://about.gitlab.com/about/#stewardship
What about having a single product, and charging for a proprietary license + support? This may work better with GPL as many large orgs are allergic to it.
With MIT license, many sites probably just implement the branding changes etc in the CE product on their own.
We want to give large orgs the option to run GitLab without having to pay us. We don't mind having people add features to CE, these are the same people that will send enahancements upstream and make GitLab better for everyone.
I'm pretty sure they take outside contributions for CE, so if that was AGPL3 they wouldn't be able to use it in Gitlab EE, which sounds like shooting themselves in the foot.
Instead of offering a free EE license I think the better thing to do is to open source features in EE that are deemed essential. So if you run a significant open source project and are considering switching to self hosted GitLab please let us know what EE features are blocking you (if any). This will allow us to open source them.
systse, I have nothing of value to add to this topic but as usual I want to thank you guys for the work you do. Gitlab may not be perfect but it's heartwarming to see an awesome open source project being supported like this and it's always really nice to see companies thrive on FOSS-first models.
Well, I can understand that having a business model which actually is stable and makes around FLOSS is hard, so I can tolerate a lot of wiggling around the edges of freedom. However, what I cannot tolerate is freedom of my data. Our IT guys are uneasy to installing supported version of GitLab internally (aside from the small question of money), because they are afraid that once we install EE version, we are locked into it. Is there a supported way how to get from EE to the true opensource version of GitLab and not to loose any data (aside from functionality not available in CE)?
I'm still considering what to do with git.xiph.org and trac.xiph.org, and gitlab is one of the options. One thing I know for sure, just as with Videolan, a proprietary licensed solution like the EE is out of the question.
> If this is essential for you we'll give you a free lifetime license for GitLab EE.
While I get the sentiment, I don't think this helps. If you want to help the Open Source community, give us what we need in the form of open source. If I don't care about vendor lock-in I can go ahead and use GitHub. GitLab counts because its open source, and its open source version is the only thing the open source community should care about.
That makes sense and we want to make sure GitLab CE is a great solution for open source projects. If there is an EE feature that is would come up frequently in these conversations we would not hesitate to open source it.
this is probably not the right forum to express this on, but it's what's in front of me right now and it's topical, so here it goes:
I have seen the feature of being able to customize the login screen come up in discussions about gitlab come up so many times, in so many places, and I usually see it met with "EE feature" or a community member saying something like "gitlab is open source just change the files on your server".
This seems like such a basic thing for an open source software like gitlab to just provide out of the box, i can't believe it isn't listed under your " ... an EE feature that is would come up frequently in these conversations ... " that you "would not hesitate to open source". Especially since at least several of the people you're replying to in this thread have mentioned it specifically.
Is gitlab really making enough income from enterprises who decide that this is the killer feature that they need to pay for EE to get?
It seems like a simple matter of moving the gitlab branding on the login page to the footer with a "powered by gitlab" type of thing and a logo.
Please don't take my meaning as a hateful rant, I love gitlab and personally manage 2 seperate deployments of gitlab CE, but i am not ashamed of saying that this is something of a frusteration to me, and I have a hard time taking this
>If there is an EE feature that is would come up frequently in these conversations we would not hesitate to open source it
statement seriously in light of how many times I have seen this seemingly harmless feature shot down for essentially no real reason.
> Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them.
On a technical level that seems an impossible distinction to make. Someone wanting to host a new project could just fork yours, then make a a commit that deletes everything currently in there, then start their new project.
Yet, there is still differences. Allowing only "fork" is a good and easy thing.
Having a fork that delete everything and start a new projet is easy to detect and label as spam. (there will always be abuses, but it's okay as long as you can mitigate/moderate)
I'd think it's pretty easy to have a policy that says "only VLC forks or VLC-related projects". What if someone wants to pull out part of VLC into its own library?
On your own instance, disallow creation or restrict of further projects. Ask people to use the 'Import any repo by URL' feature in GitLab on their own instance / GitLab.com.
We're planning to add cross-server merge requests in the future, which would make it that you don't have to host the forks yourself [0].
It would still send a signal of "please don't do that" - and could be "enforced" with some change/diff tracking in a cron job (all files changed removed - prompt someone to have a look, or just freeze access for a week/month then schedule for deletion).
Did you guys evaluate Phabricator? I wish more people knew it existed and wouldn't pick such "sideways" moves like GitHub to GitLab in an effort to be more "open source" philosophically speaking.
> we'd love to allow external people to fork our repos
I wonder if this could be solved by making it really easy to fork your repos, but when that happens the fork ends up (with tight integration) back on the/a public GitLab instance.
> Especially, it seems to be impossible to add custom searchable fields (like "platforms", "priority" or "modules") which are very very useful to do queries. Also, there is no way to do custom queries and store them ("I want all the bugs for Windows, which are related to the interface modules").
Isn't this use-case covered by Gitlab's issue labels?
I don't know gitlab very well, but I maintained a few trac instances - the thing about trac is that it is (was) an issue-tracker framework rather than a one-size-fits-all out-of-the-box solution. Have a look at:
And there's a lot of things available before adding custom plugins.
I'd be interested to hear what limits vlc hit in trac (and why they'd rather move than improve trac. Nothing wrong with that - but I confess I have a soft spot for trac and the team's ethos of "try it as a plugin before making it a core feature").
Also curious if anyone know what, if anything happened with the Apache Bloodhound fork/distribution?
I always hoped it held the promise of being a simple to install, opinionated trac for multiple (lean?) projects. But as far as I can tell it was pretty much abandoned.
While part of it might be rails-angst and fear of precious stones - I always felt gitlab was a bit of a heavy hammer in terms of install/dependencies/cloc for "just" project management.
In practice the bundled distribution alleviates that - but I still feel taking the "best of trac" and writing a new system a little more opinionated (and probably with a clearer data model) would be worthwhile. Just another project on the todo-heap :)
We want for every bug, that a few custom fields are always defined, to do a partition of the bugs, and to be able to query on those. Moreover, to change the priority or the platform, it's quite complex to do and will break often. Many bugs won't have it filled, for example. Labels do not guarantee that consistency.
As you can see, it's already what people want in the github open letter.
Just curious, what options would be there for a platform filed? What I'm aiming at are issues that are present on all mobile platforms, all desktop platforms, all x86, ... etc. Either you'd have another dozen of cross-categories or you'd have to use something like check-boxes, which are essentially labels.
Maybe having some set of mandatory labels? I.e. at least one label from platform list, at least one label from priority list, etc...
If you have to create a label for every platform you support and every existing priority and module, the labels list will become really cluttered, making it hard to find things.
It becomes very long, but it doesn't seem overly cluttered, and it avoids the risk of overly restrictive either/or classification. Rust makes extensive uses of labels on github, they're up to 120 at this point[0] and it seems to work reasonably well even with old issues with a fair number of labels[1]
FWIW, at my office for the small projects we have tracked, we use a similar method.
type-label
Types:
b - bug
f - feature
p - priority
t - team
So we might have issues tagged "p-med b-confirmed t-group1"
Once there is a method to the madness, it's not bad, and it's more flexible on Gitlab's part I'm sure, to have people tag instead of supporting custom drop-down attributes.
Can I just take this moment to say I love VLC; it's one of the best and most reliable programs ever; it does EXACTLY what I want 100% of the time and I am always astounded to discover some neat feature that fits some odd need I have. To you and your team, thank you so much for making it so effortless to watch so many different things without having to worry about formats, codecs, subtitles, audio tracks being off, etc etc etc. Thank you so much.
I still don't know how I feel about GitLab. My initial reaction was that they were an underhanded, cheap knockoff of GitHub. It felt kind of dirty, like they were stealing GitHub's thunder and giving it away for free. Then they started charging for enterprise features and turned it into a business, which felt even weirder. And then they raised a lot of money, which kind of made them seem more legitimate. And now this letter, which changed my perspective quite a lot. I didn't know that had features like voting on issues, and issue templates.
So now it even feels like they're doing Git hosting the right way, making the core software open source, and charging for enterprise features.
On the other hand, I would have probably never paid for GitHub if they followed this model. So I don't think GitHub would have been as successful.
I think you are right about how GitLab started. There is, and there should be, a lot of frustration about the biggest open source hub (GitHub) not being open-source themselves. This feels backwards and creates a harsh dictatorship that shouldn't be. GitLab tried to solve that by making an open source version and because it now can be improved upon by everybody new features start to appear. I love the self hosted aspect of GitLab and I think they should keep focussing on that however their instance of GitLab [1] is notoriously slow and unreliable. A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub
> A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub
Can you comment more on why a hobbyist should not need their own repo? If I'm doing SaaS for everything, my monthly costs start to go up.
I've found it is far cheaper, and far (way!) more educational to take an extra box out of the basement and install Ubuntu/GitLab/Node/Java/Apache/Etc.
I have to pay for internet either way, and the electricity cost is nowhere near the cost of having multiple Saas?
Most of the time, it's because of opportunity cost: The time you're spending building a server, learning how to manage repos, setting up redundancy and just trying to get the thing working, you could've spent on whatever product you were trying to produce, and would likely be much further along with if you hadn't done everything the hard way.
That's not to say there isn't educational value, but a common piece of advice I've gotten is "Don't optimize for anything but your life." Or more easily explained: Don't optimize for things you don't need to.
The opportunity cost on the front side is often worth it but the long term benefit on the back side is you aren't dependent on that SaaS, are running stuff you know something about and have a lot of flexibility.
I'm from the old school, I use SaaS/PaaS mostly for stuff I know is painful to do yourself (sometimes file storage, nearly always email) but the rest lives on vanilla boxes configured with ansible (frankly ansible is faster to use once you get your head around it than learning 5 different PaaS setups).
The ansible docs are excellent and walk you through the process, one thing I did (and would suggest) is use vagrant (or similar) with ansible, it has built in support for it and it allows you build/tear-down way faster while you are learning.
Building on the other answers, I think it is more awful for pros. Hobbyists don't have deadlines and spend time on computers because of love, not to pay rent.
That said, you do have a point, and you decide what matters to you as a hobbyist (or whatever you decide to call yourself).
I personally like (and need, most of the time) stuff that "just works", so I totally get your point about optimizing and agree with it.
I'm personally glad to have done things the hard way,
sure it took some time to learn but learning sysadmin made me a better developer.
To me, setting up a repository, an issue tracker, a wiki etc. was more about learning about a process than learning "how to make it work on the server".
Process as "how to organise the production of writing software" and this is imho extremely important, I reuse what I learned all the time from web app to mobile app to server backend etc.
Simply put, I see a lot of people who fail to deal with software production simply because they just use the tool "a la mode" like Github, but are completely oblivious to the benefits of using semantic versioning, an issue tracker, a wiki for documentation, etc.
When you learn all that by yourself, you can compare different tools and have a feel for what's a "bare minimum", you just know how to manage/organise a project a make it work in production.
> A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub
I completely disagree, here a little story
before 2005 I was hosting my own SVN repos, then came a community "we host your open source project for free" and I moved my sources there
and it closed, so I moved all my repos (they kept growing) to google code
my main reason to move to google code was "its' google they will never close down"
guess what? few years later, google code close down
at that point I decided NERVER EVER AGAIN, I moved all my repos to my own private dedicated server
now I do use Github but as a mirror, they can close down tomorrow I don't care (note: I don't wish them that)
Some people take their repositories very seriously, hobbyist or not, for me it's like backup you only see how important the infrastructure is when the shit hits the fan.
Things like Github, Gitlab, etc. are nice but it's merely a beautiful web UI on top of what is important: the repository.
My point is even if you are an hobbyist you should own and control your repository, if you can host it on a dedicated server, or at home on a spare box, whatever, do it, do own it (the infra), yes because a tarball archive of your repo and a JSON export of your issues is completely useless.
Doesn't every distributed system let you keep your own repo under your control? I have all my projects on github but if github disappeared tomorrow I'd just push my repos to a different service.
As a hobbyist I only commit one small thing a week or so without any issues. I'm curious what stability issues they have for later projects, if you'd care to elucidate?
We are dealing with a lot of sensitive data and code which is legally not allowed to physically leave our group and GitLab is in my opinion the best open source choice for that.
I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)
I wonder why they advertise the "platform"/implementation language so clearly (in this case Go). It shouldn't matter for the users? I get sceptical, as if the only reason they exist is to provide the same service but in a new implementation.
I've been using Gogs for personal use for a while. I love its speed and its simplicity.
That said, it's probably not a good fit for most businesses at this point. It's relatively new, and mostly maintained by a single developer, who spent the last summer on vacation.
He's very active when he's around, and almost always working on improving Gogs, but there's a lot of people with features requests (the issue that's always getting comments today is for opening pull requests across branches within a single repository -- i.e. not forking.)
Yes, because not everyone uses Docker yet. Some may never adopt it. So long as that remains a viable path, then the matter of deployment systems and complexity is relevant.
There's also Stash (now renamed to BitBucket Server (edit: fixed name, as pointed out in the reply)). It does not include some of the features (such as issue tracking), and I think rightly so. I haven't used GitLab for maybe 2 years now, so I can't compare the two.
Umm no, you are incorrect. Bitbucket does have its own issue tracker like GitHub.. (but it is not turned on by default) and what I am referring to is NOT JIRA Software.
We've been using GitLab CE internally in our organization for more than a year. We needed an on-premises solution because of the company's policy. The experience has been great thus far.
On EE, there's nothing that we miss from the EE version, although we might end up going with EE after the team will grow. We also have dedicated dev-ops, otherwise having support for it would sounds good. And the pricing for EE if you go that route is much better than for GitHub Enterprise.
Personally I have mixed feelings about the "open core" model, as many times it's just a marketing stunt. But for now that's not the case with GitLab.
> I still don't know how I feel about GitLab. My initial reaction was that they were an underhanded, cheap knockoff of GitHub. It felt kind of dirty, like they were stealing GitHub's thunder and giving it away for free.
Richard Stallman is the "prophet" of free software. The EE license is not a free software license (and probably isn't an open source one either). The given license doesn't give you any of the four essential freedoms.
I've recently made an iOS App that integrates with GitLab. The people at GitLab have been incredible, they respond to my issues, improve the API with every release, I didn't expect this level of awesomeness when I started the project.
What's great about GitLab, there's a release on the 22nd of each month, so you can depend on pretty much continual improvement. Even if you don't think GitLab is suitable for your Open Source project, talk to the team on their issue tracker, things get solved pretty quickly!
Because Matt is too nice to plug his own app, I will do it for him. Check out Trident: http://www.somerobots.com/trident.html It's a really nice app and we are happy to make improvements on our side to make it even more capable with every release :)
Thanks for building Trident! Happy customer here. Gitlab servers work really well and is super fast. Patiently waiting for the Github servers functionallity to be on par with the Gitlab one :)
Appreciate this compliment :) Please open any issues you see with the App in the issue tracker, helps me prioritise new features and candid feedback helps!
As a quite disappointed user of Gitlab (due to issues raised here, e,g, CE vs EE and the Ruby infrastructure), has anyone had experience with both? I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share?
Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
We've been using Phabricator for a few months, coming from private repos on Github.com. We initially liked it because it "ticked all the boxes" for the features that we needed from a source code and issue tracker. However, we ran into major issues along the way, basically because some of the concepts in Phabricator aren't compatible with our workflow. We decided to switch to Github Enterprise and haven't looked back since.
Some of the issues we had with Phabricator:
1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team.
2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.
3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)
4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.
In the end Phabricator just wasn't the right tool for us. It definitely has some attractive properties: it's easy to install and upgrade, the command line tools are solid and provide all functionality you need, and it performs extremely well even on a small EC2 instance.
> 1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team.
The features which aren't explicitly marked "experimental" work very, very well in my experience. Especially the code review part, which I find more pleasant to use than Gerrit.
> 2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.
Have you got some examples? They're hiding the database pretty well IMO, and we haven't had many usability complaints that weren't about minor issues. Many of the experimental features are cumbersome to use though and we've turned off some of them again to avoid confusion.
> 3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)
Have you raised an issue about this? They're very responsive to issues encountered in real-world use and usually decide about feature requests by user demand. I do know that they're working on improving this - the "callsigns" will become optional, for example.
> 4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.
Their way of doing (or actually, not doing) pull requests is the most important feature of Phabricator. Their approach scales much better than the traditional style and is - in my opinion - the most important reason to choose Phabricator over Github-style tools. This might not matter for small projects, but in a company, it sure does.
Hi, sorry for my late reply, apparently I'm not notified of responses to comments :-).
1. That's true; the non-experimental parts of the suite are mature and work really well.
2. This was most apparent in experimental features like Harbourmaster/Drydock, where you need a lot of clicking around to configure a basic build setup. Granted, that didn't apply as much to the core applications, but we didn't find those very user friendly too. The task detail screen in Maniphest, for example, is super-cluttered with all kinds of labels, links, and text in the main panel of that screen. Also, the fluid layout in Maniphest makes it hard to read task descriptions/comments because lines of text get very long.
3. No, we didn't, because we were going to switch away to Github Enterprise anyway. You're right about responsiveness of the team, we noticed that too, and that's really nice.
4. Exactly, code review is how Phabricator started and I can definitely see merits in their approach. However, we aren't interested in changing the core workflow of 15 engineers just because it's theoretically a better way of doing code review. We're getting actual work done just fine with Github's PR system, despite the flaws it has, and that was one of the main motivations to go back to Github (Enterprise, in this case).
Like I said earlier: I think Phabricator is actually a very nice tool and I can see how it works really well for large teams that are willing to commit to the code review style. It just wasn't the right tool for us :-).
> Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
I'd prefer it to be written in something else, too, but - the Phacility team are ex-Facebook developers. If anyone knows how to use PHP, it's them. They built their own, extensive web application framework on top of it (which is a remarkable achievement for itself). Phabricator is one of those rare examples that you can, in fact, write excellent code in PHP.
I'm primarily a Ruby developer, but my current gig has me working exclusively in PHP (and worse yet, Wordpress). PHP as a language is actually pretty stellar these days. There are things about it that I dislike, but there has been a lot of recent work put in to improving the language. I'm always finding nice features.
Really the place that PHP is lacking is on the tooling/ops side of the projects built on top of it. A lot of what I have to work with still seems to be 15 years old. That said, it's getting better and other peoples' preferred tools have their share of problems as well.
> I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share?
I think GitHub is prettier, but having tasks separate from repos and having tasks be as sophisticated as they are in Phabricator and having such a better pull requests system, it doesn't matter? GitHub has to dumb down the user interface on their product to appeal to the least common denominator and maintain their growth. Phabricator is for projects where people care enough about their projects to learn the UI so they can get things done.
> Also, do they pride themselves for writing this in PHP?
As a user I doubt you're going to find your self caring about how it's written.
As a user of a self-hosted web service, how it's written affects details about the pain of deployment and administration. How it's written also affects whether it has satisfactory performance and how many nasty security problems are waiting to be discovered.
Not everyone can afford to be completely blase about their source control system going down or getting defaced.
PHP apps are a hell of a lot easier to keep up-to-date than the unholy hell of Rails apps, especially when you discover developers have started locking dependencies to old gems with known security issues.
Phabricator is super easy to maintain. The out-of-the-box experience is better than any complete solution I've tried, including gitlab.
That being said, just like any other fairly complete solution, it's quite opinionated about the right way to do things, and it's very different from github or gitlab. In particular, since it is not tied to git, it duplicates some of git's functionality in its own tools. In many ways I find those tools to be better than what git uses (arcanist just seems more well thought-out from a UI perspective), but it is a learning curve.
If you are happy with svn or hg, and don't want to have to switch to git, Phabricator is a no-brainer. If your team is a bunch of super-advanced git users, they may not like having to learn a different way of doing things.
A note - the Phabricator core team have been reticent in merging changes or features that they don't themselves depend on upstream. If you need anything that isn't offered out of the box or on the roadmap, be prepared to maintain your own fork of Phabricator indefinitely.
I started looking into GitLab and Phabricator around August/September 2014 for my company. My criteria was primarily based around something to assist with code review. Ultimately I went with Phabricator for several reasons:
1. Supports Mercurial - our repositories are currently in mercurial, and using any other tool would require switching to git (which we seriously considered while looking at tools).
2. Simple to maintain - if you have experience setting up other web applications based around LAMP, this is essentially very similar. The web interface even indicates setup issues to admins, from things which can cause issues to performance configurations in things such as MySQL and PHP.
3. The code review interface was more intuitive for myself and other engineers. From the command-line tool (Arcanist) to how it's conveyed to the user in the web interface. It did take a little time to fully comprehend and implement the process for using, but since implementing in Feb. of last year, after around 4 months we had near 100% adoption by the engineering department. The GitLab/GitHub interfaces I've found to not be organized intuitively -- the lifetime of an issue/changes seems (seemed?) more social-based and intermized where in Phabricator an Issue/Task is almost separate from the changes which can go into it, though they reference eachother easily.
>Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
I had the same reaction at first (thought I wouldn't say it's pride?). In fact the first time I looked at Phabricator (~2012) I totally dismissed it for three reasons:
1. Written in PHP
2. Mentions pokemon on the front page
3. Marketed as "collection of open source web applications"
These led me to believe that it was at most some PHP glue some students hacked together to get different unrelated applications to play together. This conclusion is entirely wrong. I've since changed my mind about PHP - biased from earlier experiences there's no reason to think a reliable/stable application couldn't be built on it. Phabricator (I believe) started as an internal application at Facebook which has since become its own company. The code is very well organized (I've contributed some small changes), and there are some very bright people working on the project - I get the vibe that they genuinely want to solve the right problems rather than checking features off a list. There are very few dependencies on other libraries unless you specifically decide to enable extra features, and even then there's some support/documentation there to assist. Despite the light-hearted humor (see pokemon) that is a staple of the software (unless you enabled serious-business mode), the project is designed and developed by highly capable, quality professionals.
I couldn't have been happier going with Phabricator over GitLab.
We had a go at Phabricator for code review. Suddenly, there were two opposing camps - those who hated it utterly and those who loved it and wanted to tweak the heck out of it.
Fortunately (for my team at the time, which was very resource constrained) those who hated it eventually won, but I, being kind of on the fence regarding it (wasn't keen on the UX, but liked the features), sort of wondered what would happen if someone improved the UX beyond the tipping point.
My company with ~300 developers are moving to Gitlab in the next few months. Today our CTO/PM shared opinion about Gitlab and he was very happy we're doing it, even better I recommended it to him :)
I'm a Gitlab users for a few years now, personally I like it much more than Github, one of the reason is that I fear that Github contains too many projects and gains too much control over OSS, I also dislike their CoS.
> one of the reason is that I fear that Github contains too many projects and gains too much control over OSS
I don't understand this fear. All repositories on GitHub can be hosted elsewhere. Moving metadata (e.g. issues, milestones, PRs, etc.) is more difficult but mostly possible.
Disclaimer: I like that GitHub is the "central" place for OSS, it makes my life much easier. I know how to use the product very well and it's convenient having almost every project that interests me available there.
Monopoly. Github enforces their CoC which has nothing do to with good coding practices or technological progress, they ban repositories and people based on their views expressed in comments.
One issue that was raised several times was the ability to not create merge commits. In GitLab you can, as an alternative to the merge commits, use fast-forward merges or have merge requests be automatically rebased.
The main thing keeping me from actually doing it is the network effect... and this:
Disadvantages
Right now GitLab.com is really slow and frequently down. This is because of fast growth in 2015.
I think taking the conservative approach of not re-writing history (--no-ff) is appropriate for a service like github. It is easy to ff merge PRs from the command line.
Thanks! We're very glad to be on the front page and hopefully get more people contributing and discussing features. GitLab.com is now at a size were the HN crowd doesn't make a dent. But the HN crowd is very important because they are frequently active contributors. We are trying to solve the speed of GitLab.com even if we grow 10x over a few months.
There is already built-in support for pull request[1] and patch based workflows in Git itself. Why do we need to wait for, and choose based on, hosted services providing things like that? EDIT: for more clarity; using pull requests and patches with Git itself means that it simple to rebase or whatever, since you're just working with branches and patches directly.
Or am I missing something? Other than something like usability, perhaps...
[1] I'm not actually quite sure if there is a specific command for that format. Though it should be easy enough to have a third party solution that uses a format through email.
I hate that github does pull request merges with --no-ff, so what happens is that I manually pull the PR, merge it locally, and push. Github is nice enough to notice that the PR was merged, so its status is appropriately closed (if that was a fast forward, I don't think it detects rebases), but that makes me have to go out of the browser to start typing commands when I could have just clicked a button and be done with it. Essentially, it's a smoothness problem.
GitLab.com runs GitLab EE. So - if you compare features of github hosted and gitlab hosted, it's best to compare EE. (For example, GitLab.com hosts private repos, for free, and it's EE.)
If GitLab plays their cards right, they can take the market from github. That, in my book, will be good because unlike github, we can all contribute to making GitLab better.
The only question left is if your servers are powerful enough to run gitlab. Maybe I'll sacrifice a goat for some new server hardware and 256GB of ram.
By the way, I don't want to troll you, but at my company we use Gitlab 6 self hosted version and I wasn't able to do a simple git push origin master
the repo I held in my machine was barely 5MB and still remote server closed connection HTTP 500
I solved it by increasing the POST buffer.
I never had this issue with github, maybe you can check why it was an issue with gitlab? it might help to advance your product!
GitLab introduced a new web server (gitlab-workhorse) in 8.0 that's better at handling large HTTP requests. I would suggest upgrading (not just for that reason, there have been tons of improvements and security updates).
Could you explain what still needs to be done? I use Gogs for personal use, but evaluated Gitlab briefly and it seemed about as polished, if not moreso, as Github to me.
I chose Gitlab for my former company over GitHub Enterprise because we wanted an on-prem solution, and it worked well enough for ~200 folk. We did have to tweak (and occasionally break) a few things, since quite a few people suffered from NIH syndrome and wanted things done "the right way".
In general, I liked it, but it always irked me that its Ruby underpinnings made it hard to upgrade/migrate stuff (we basically just swapped LXC containers at one point, not sure how it was handled during the last upgrade). If anyone ever manages to do a credible alternative that does _not_ use Ruby in any way but keeps the overall GitHub-like workflow, a lot of operations folks will switch _instantly_.
Also, like some commenters already pointed out, the CE edition was ridiculously limited in some regards - we mostly skipped the bits we didn't like and did product-level ticketing outside it (using Trac), with Gitlab issues used only for "techie" stuff, tracking fixes, etc.
But today I'd probably just sign us all up for GitHub and be done with it, or fire up a VM image from some marketplace - there's hardly any point in maintaining our own infrastructure or doing a lot of customization.
Nowadays, the omnibus package makes gitlab pretty easy to maintain.
I had to do an upgrade from Gitlab 6.9 (source-based on ubuntu 12.04) to 8.3 (omnibus rpm on rhel7, managed via puppet) recently, and it was surprisingly smooth.
The package-based installer bundles all the needed software, which is quite okay for software like gitlab that often depends on specific versions of auxiliary software. It uses a built-in chef to configure its components.
I performed the upgrade in two steps, first to 7.14 (on the source-based install), then did a backup/restore to the new server with omnibus and upgraded it to 8.3.3 with yum.
Gitlab migrated the database mostly correctly (there were some issues with the LDAP provider; some users had the wrong provider in the database, but that was easy to fix manually. I'm not sure what caused it) which was quite a surprise considering I went up 2 major versions in two steps. Even upgrading the source-based installation went very smoothly even though it had to download a couple dozen ruby gems from the internet.
The upgrade also affected CI functionality for one of our users but I think that was because it relied on pre 8.0 non-builtin CI, and simply needed reconfiguration for the new system.
Afterwards, a point-release upgrade took a whopping 5 minutes (most of which was downloading and extracting the new RPM).
1. For starters (besides other internal stuff), we were the guys who needed Shibboleth support. You might recall there were a few pull requests from a colleague of mine regarding that :)
2. No, we had to tweak the source, so I don't think the packages were useful.
3. Static pages, hooks and merge approvals would be right at the top of my list. Audits would be nice to have, but we figured out how to do that on our own.
Also, issue handling needs some improvement. We just couldn't map our Trac workflow to it - but that's a fairly longer story, and it would probably be the same if we used GitHub.
GitHub Enterprise was essentially a closed VM that did not allow us to do the sort of customisation we needed - nor, most crucially, mount the git repos from our enterprise SAN.
Gitlab allowed us to do that without any hassle, even running inside an LXC container.
I've been using GitLab instead of GitHub recently for all my new projects and honestly there's nothing worse than GitHub and a few things are better - like having protected branches and master by default in it -, private respositories etc.
That being said, what both GitHub and GitLab are missing is actually becoming a "social network" or maybe more an active network. There are tons of interesting projects that pops up every day, that I would be interested in knowing about, contributing, but there's basically no way to learn about them.
I have never used GitLab myself, but some of the features mentioned in the article (like a true voting system) is something I've really longed for. Might have to reconsider trying out GitLab more.
I remember GitLab. They interviewed myself and a bunch of my colleagues to test the salary waters here in the Bay Area and hired nobody because we were all "overpriced", with several being underpaid for the area.
If you want the talent you need, especially in the Bay Area, you have to pay more than what the average developer makes in Amsterdam. I want to like GitLab, but I just can't get that bad taste out of my mouth.
We never interview people to test the salary waters, we know interviewing is serious for you and it is serious to us too. We're very aware of the salaries in SF (writing this from SOMA). But since we're a remote first company we can hire for anywhere in the world and because we're open source we get a lot of great applicants. So the bar is high and for the Bay Area it is even higher. Feel free to email me at sytse at company domain if you want to discuss your application.
If you know you're not going to pay SF (or even US) sized salaries, why waste everybody's time with multiple interviews then? State up front "We're only willing to pay $80k, even if you've got the history (previous salary, measured prior project impact, demonstrated skill in the areas we need, etc) to justify 2x or 3x that". You won't be able to pick your interviewees brains on possible solutions, but you also won't be wasting their (and your) time.
We don't want to waste anybody's time, actually efficiency is one of our values https://about.gitlab.com/handbook/#values. We do pay SF and US salaries (see https://about.gitlab.com/team/ for an idea where our team is). But as said the higher the salary the higher the bar. We think there are exceptional people in the SF Bay area and we would like them to work for us.
I tried to figure out a salary range for positions to prevent wasting everybody's time. But we still very frequently go higher or lower than I guessed based on the person's ability and their location (and cost of living).
I would like to prevent disappointing people like bitshepherd and I'm open to suggestions.
My suggestion would be to be completely up front in what you're willing to pay, even going so far as to add it to the job description. If that means you have salary 'bands' dependent on what region of the US an applicant is from, put 'em up.
Ninja-edit: also, if the money just isn't there, consider taking on someone on a part-time basis. $80k/yr is terrible FT wages for the senior-level folks you're looking for, but if you say "We'll pay you $80k, and you just clock in M-W 9-5 (or M-F 9-1, however the math makes sense for you to divvy up a 20-hour week)" I think you'll see an uptick in interested, qualified applicants. Yes, it's a compromise (just like asking a senior-level anything to show up for $80k) but at least you'll get the senior-level brainpower on the team and still be within your budget.
Ninja-edit x2: Looking at the 'Team' page, I'm not getting a good sense of where your devops/engineering talent hails from. The folks who appear the most USian are the guy who lives 'on a farm', another who 'attends SFO Giants games', a third who 'enjoys the slopes in the Sierra Nevadas', etc. Everyone else's location is either unmentioned, or they seem to hail from Brazil, the UK, Greece, etc. The interactive map at the top seems to be mapping the accounts of suits and c-levels, but very few devops/engineers.
Thanks for looking into this and your suggestions.
I think the salary bands per region is an interesting idea. If we would have these today we would put them up.
In some functions (for example finance) we have part-time team members. But in a fast growing startup it makes sense to have many full-time people to reduce (communication) overhead. We are prepared to pay up where that is needed. We do allow flexible workdays for everyone. And based on ability and responsibility we also consider 4 day workweeks.
The map at the top is something we invite all our team members to join. Currently we don't have any engineers living in SF/NYC. We do have other team members in sales, finance and marketing living in SF and NYC. I do expect us to higher one or two engineers in SF in the coming months.
Consider setting up an office in Bangalore, you can find great developers here and considering the cost of living differences you won't have to pay a lot.
Well, Bay Area salaries have gotten way out of hand in the past few years, mostly due to the cost of living there, but that is besides the point.
Since we are a remote company we have the luxury to be able to hire amazing engineers from all over the world. Paying 1 Dev salary in the Bay Area is almost the same as paying 2 salaries in Europe, or even 5 in Latin America. Talented people can be found everywhere, not just the bay area.
And having a global workforce also allows us to have the best people with a vast variety of backgrounds, which also contributes to our culture.
Interesting. Yours is not the first account of a poor interview process with GitLab that I've heard. Even out of Texas, had a few colleagues that were very qualified and came out of it with a poor experience, to the point of changing their mind about wanting to work at GitLab.
Great PR move by gitlab, and I don't mean that negatively. This kind of direct response is exactly what a company looking to improve should do, hats off to gitlab!
Once their performance increases, maybe we'll see the momentum shift from Github.
Please improve your mobile UI - phones have lesser horizontal space than vertical. You have put a cool looking sidebar on the left side which takes up a lot of space causing text layout to be funny on my 5.2 inch LG G2.
You should be able to collapse the left sidebar. But we are the mobile UI has deteriorated in the last few releases and we plan to look into it in the coming months. If you want to get paid to contribute, we're hiring front-end engineers https://about.gitlab.com/jobs/
A migration to Gitlab. GitHub would have to start fucking the developers asses in a serious and violent way for them to move to another place, the same way that the SourceForge -> GitHub move was done.
Perhaps if they had the same uptime, page load speed and UX as Github, I would consider it. Unfortunately we tried it for a week at work and none of us could figure out our way around it (when it was working).
I'm sorry that GitLab.com was unavailable an slow. As mentioned on https://about.gitlab.com/gitlab-com/ we're working on that. Have you considered self-hosting it?
While I've always admired GitLab being a free software alternative to GitHub, the whole EE licensing stuff really rubs me the wrong way. EE is completely proprietary software, even for people who have paid for it (it only allows the freedom to modify the code, but you cannot run it as you wish or distribute code freely). I understand charging money for your software, but you can also charge for feature requests and support. There's no need to lock away features from people using your free software just because you've deemed that feature "not useful for you" or "pay-to-use".
What I really don't get is the argument that "we won't liberate feature XYZ from EE because it's only useful for companies with 100+ developers". I think it's quite impressive that you can know what every user of your free software needs, and that you'll protect them from code only suited for enterprise.
I'll still use GitLab (the fact there's a free software version is great), and I'll be the first to fork (or back someone else's fork) CE as soon as you get acquired and your free software is no longer maintained by you (see: Oracle with Solaris, and every other acquahire ever).
What do you mean with 'cannot run it as you wish'?
Regarding choosing features for EE, I recently updated the text on https://about.gitlab.com/about/#stewardship to read "is this feature much more relevant for organizations that have more than 100 developers?". Obviously every features is relevant to smaller organizations too. We make a guess and if we find out we guessed wrong we'll open source the feature, as happened today in this article https://gitlab.com/gitlab-org/gitlab-ce/issues/11489
At least with Gitlab I can open an issue somewhere and follow it, like with open source projects. It doesn't disappear into the abyss with no feedback on what's happening.
I've implemented two self-hosted Gitlab instances at work, for one of the instances on our private network, I'm still fighting with IT to allow us to use LDAP. Gitlab EE is still off our 'pockets' as management aren't too keen to pay for it, at least yet, but I hope that we'll get there.
Our self-hosted instance is also a bit slow, not as slow as Gitlab.com, and if it was written in a language that I'm familiar with, perhaps I and some of my team could contribute to 'making it faster'. Pity I don't have enough time left in the day to learn Ruby. I've read up a bit on the work going on around Unicorn and workers, but maybe some of these things could be better written in other more 'performant' languages?
For personal projects I still use Bitbucket + JIRA. I got to the point where I decided to stop looking for freebies and pay. JIRA has been awesome, totally worth the price.
Congratulations on GitLab, I personally use it and love it, and it's awesome to see amazing people like the VLC team considering GitLab.
A suggestion I have is to consider open-sourcing and re-branding EE on a GPL-Like license that also requires projects hosted with it to be open sourced, while specifying that contributions to this version can be re-licensed by GitLab to be used by paying customers (Or re-licensed to MIT and released on CE). This way open source people get it all, and if you want to use it on closed source you pay GitLab.
This also has the benefit of allowing open source developers to work with GPL, and the changing to MIT could even be decided before merging (Sending to either CE on MIT or EE on GPL+GitLabProprietary, according to developer decision).
There's a lot to fix on the OpenSource world, but there are also so many possible ways. Best of luck to the GitLab team, I hope we see more amazing stuff from you (Btw, GitLab CI got a lot better recently, I hope you keep improving it. :D)
Thanks for the kind words Ellahn. You suggestion is interesting. I'm afraid that releasing EE under a GPL-like license that prevents private projects is confusing. It would be GPL-like instead of GPL. I think that such a license muddles the waters and would not be in the best interest of open source. I presume that people want to be free to do as they please with the software, not be restricted to how they use it.
For me the big things missing (not only for big open source projects)
1. more than one level of subdivision for groups/projects (see below)
2. groups of users (call it department/team): because of 1 we have a lot of groups, (because all the small libs are in separate projects, so the project itself is a group, but of course we have several projects), so everytime somebody join the company, we have to add him in every single project (for them to be able to read the code), and we have also subcontractors, we would like to have a nice way to separate from the others
I think this things are most "day to day annoying", other than that gitlab is pretty good, the CI system, the hook system, it's pretty easy to put that links to issue section, ticket reference redirect to redmine , taiga , jira or whatever.
I've been using GitLab myself and suggesting it to any clients with the proper infrastructure. When I found GitLab I tried it out, and finally ended up moving my SVN to Git (private projects). It's a great piece of software and I love the web hooks.
Arguments from the project/push add to url would be great! A page outlining why you are better than gitblit would help with clients :-) (who are all possible future EE users)
Thanks! I created an issue here [0], I'd love it if you could clarify it a bit there.
I think we can do better in our comparisons with competitors. I created an issue [1]. I haven't heard someone asking before about a comparison with Gitblit. Please feel free to email me at job at companyname dotcom if you'd like me to discuss it with your clients.
Gitlab might have the resources to properly support multiple vcs' - but even though I personally prefer mercurial (ui, reasonable large-file support) - I'm not sure it would be a good idea. Trac (trac.edgewall.org) did a lot of feature-experimentation -- and I think one take-away is that being an effective workflow support tool and supporting (even subtly) different back-ends with accompanying different best-practices/patterns (eg: git sub modules) is hard.
There's no real limitations on making the two VC system compatible, that's why RhodeCode has same functionality for both Git and Mercurial, without making tradeoffs, that's why systems like hg-git could also work out quite well.
I get why GitLab wrote this, but it seems like just a stab at GitHub.
There seems to be a lot of hating on GitHub here, but I personally love GitHub (and we use GitLab at my current employer).
I think GitLab is doing a great thing, and I appreciate that their community edition is free and open source, but GitHub has been able to provide an invaluable service. They have a great community that facilitates open source projects and a vastly better UI than GitLab (though that isn't saying much with how awful GitLab's UI is).
I'm eager to see how GitHub evolves in the future with GitLab as a competitor, as GitLab has a lot of nice features (built-in CI, etc).
It is a stab and tbh Im glad they took the opportunity. There are few times when a product can be marketed to such effect for as little cost. What they did was show everyone how awesome they are and how stagnent Github is. Github can easily change but most of their decision making is done behind the scenes.
Github grew popular because it was popular. Maybe thats worth something but long term they must adapt just like Gitlab
Yeah, it's bit of a stab. I'm really curious to see how GitHub responds (if they respond). A lot of good could come out of this even if it takes some competition to force some of that.
This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems a little low-brow. Why respond to a letter that's not addressed to you? I would have preferred them to simply post an honest "Why you should migrate from Github to Gitlab" article. The tone just seems a little devious to me.
By the way, we're using self-hosted Gitlab at work and we love it. This isn't a knock against the actual product. In fact, I think Gitlab has improved tremendously in the last 18 months. I just wish they would be a little more up-front about their marketing efforts.
> This attempt by the Gitlab folks to ride the Github dissatisfaction
> wave seems a little low-brow.
There's a github dissatisfaction wave?
Anyway, opening sentence of gitlab's open letter: "The letter of GitHub’s open source community is clearly not addressed to us, but we’re thinking a lot about the issues that were mentioned in it."
Does that cover your concerns?
I think if github was the free software entity, and gitlab had no free software edition available, then the tone would be, as you suggest, totally inappropriate. However given the arrangement is the other way around, it seems quite reasonable they would hop onto this issue at this time, especially given the very clear caveat quoted above.
"Wave" might be too strong a word, but I've seen three or four posts on HN in the last few days that were pretty critical of Github's closed source nature and insufficient transparency.
I'm not sure why offering a free software edition somehow gives you a pass. Both Github and Gitlab are commercial entities as far as I know.
Anyway, my concern wasn't a big deal, I was just a bit taken aback at the opportunism. In retrospect, I think my reaction was a bit overblown.
Fair enough. I feel like there's been stories / sentiment along this line for a while, though apart from Microsoft's ChakraCore announcement last week (?), the only two specific stories I recall from last year were about github's valuation (US$2B) and when they threatened to remove someone's repository because it contained the string 'retard'.
You're right that both github and gitlab are commercial endeavours - obviously very much in the same space - so I'd expect them both to pop up in any discussion about bug & feature trackers, community involvement, etc - especially if there's the potential to improve their business.
On the other side of the coin, I'm curious why Github seems to often get a pass by the free software community.
> Why respond to a letter that's not addressed to you? I would have preferred them to simply post an honest "Why you should migrate from Github to Gitlab" article.
That's basically what they did. They said "hey, you have these issues with GitHub, we're covering them, AND we listen to the community".
I think it's great that they responded to it, since it proves they actually listen and care about what their audience thinks.
> This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems a little low-brow.
I can hardly imagine a better outcome. Now both GitHub and the developers have a choice to make; GitHub can either ignore the complaints or take them into account, and people can either continue using GitHub or start using GitLab (or something else). Nothing better than informing people in a kind, respectful manner.
Since they have employees and apparently are an ongoing business concern I would be worried if they didn't try to get their name in the conversation. If they let this huge discussion go by the wayside silently then they would be incompetent business people.
I think, that GitLab staff wrote respectfully, in an open manner.
> I think Gitlab has improved tremendously in the last 18 months.
I agree, IMO it's already better then github - I know people will disagree on that, but I find the UI way better - Easier to find things and navigate for someone who doesn't work in github very often (milestones for instance).
Yes, that's sort of the point I'm (badly) trying to get across. I think the product speaks for itself. That said, I may have misinterpreted the tone of the article.
Using gitlab for go development, "go get" doesn't work. Googled around, couldn't find a solution. With github, on the other hand, it just works.
I love gitlab (even made a git tool to easily create repositories from the commandline, gitgitlab) but these small things make a real difference. I'll end up paying for a github organization account just to get this annoyance out of the way.
What I would like to have in the free version is:
- Project importing from Stash to GitLab
- Mirror Projects
- Display merge request status for builds on Jenkins CI
- Rebase merge requests before merge
- Git hooks (commit message must mention an issue, no tag deletion, etc.)
1. Currently It's hard to migrate a whole Stash Server / Bitbucket Server.
2. Thanks
3. Oh, ok we already use a thing like that for Stash
4. Currently we are 5 people, but we use Git Hooks extensively and used a rebase workflow before we used a Stash Server.
Also we only use a special style of commits that go into our global git server, people should take time to write their commit message.
> yearly per user purchased in packs of 10 $390 per pack
Remove the Pack and we are happy. Paying monthly would help also we try to grow, but sometimes we need to shrink (if people don't fit) we move really slowly when it comes to people, we had some issue's at the beginning, so we learned from that the hard way.
Thanks, subscribed. When Google Code shut down, I migrated the IPvFoo[1] source code to GitHub, but it felt dirty using an IPv4-only service for that purpose; I'll probably move again to GitLab if they follow through.
Because the thread has turned into a "why I like/dislike GitLab over GitHub", I'll say one thing that keeps sending me back to GitHub is the neat-o desktop client.
I use a command line for everything else in life; but with Git I'm hopeless.
I currently do this for the basics, and drop down to git at the shell for anything more complex than the one or two things GitHub's client does well. It's a decent trade off in my opinion.
For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure.
And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting the change.
The first part is the groups and subgroups: it seems incredibly difficult to give sub-groups access to repos (like a team for iOS, one for Android, one for libVLC... but all are under the "videolan/" group). It seems there is a way with the EE, but not in the CE; and the current idea for the CE is to have sub-projects, which is not good, because it will make our URLs way more complex than needed.
The second part is the bugtracker/issues tracker. We use trac for VLC, and we want to leave it for something better; but gitlab issues is way too limited, even when using the templates. Especially, it seems to be impossible to add custom searchable fields (like "platforms", "priority" or "modules") which are very very useful to do queries. Also, there is no way to do custom queries and store them ("I want all the bugs for Windows, which are related to the interface modules").
If I remember correctly, this second part was also a complaint in the open letter to github.
Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them.
PS: can we have custom landing pages and custom logo in the CE version? :D :D