GitHub’s new offer closely matches that from GitLab(theregister.co.uk)
theregister.co.uk
GitHub’s new offer closely matches that from GitLab
https://www.theregister.co.uk/2020/04/15/github_core_features_free_price_drop/
97 comments
Looking through that comparison, I find it funny that "time tracking" is touted as a feature.
My grand-boss might love the idea but the fact that GitHub is missing time tracking is a blessing as a developer.
Making developers track their time is hostile. Development is not something you should clock in and out of. A time-box in JIRA or GitHub shouldn't replace management being aware of what their team(s) are working on and how their progress is.
It too often turns into a stick to beat developers with.
There are all kinds of better metrics by which to hold developers accountable. Tracking time just puts developers off from improving code or refactoring. If you write bad code it's not your time that suffers, it's the next developer who has to work on that section.
My grand-boss might love the idea but the fact that GitHub is missing time tracking is a blessing as a developer.
Making developers track their time is hostile. Development is not something you should clock in and out of. A time-box in JIRA or GitHub shouldn't replace management being aware of what their team(s) are working on and how their progress is.
It too often turns into a stick to beat developers with.
There are all kinds of better metrics by which to hold developers accountable. Tracking time just puts developers off from improving code or refactoring. If you write bad code it's not your time that suffers, it's the next developer who has to work on that section.
That's interesting feedback, I'll pass it along to the product team, although this is an angle they've probably thought about more than I have. The way we use it isn't really as an accountability metric, more of an estimate that can change dynamically when new problems arise so we can roughly plan out when a feature is going to be released. Granted we don't have a boss who would beat us over the head with that. Thank you for the feedback though I'll make sure to pass it along.
> Granted we don't have a boss who would beat us over the head with that.
For every boss that wouldn't, there are a hundred bosses that would, with very little understanding of what is even being measured. Sure, the "guns don't kill people, gun users kill people" argument applies, but maybe don't hand people free guns with their milk purchase?
For every boss that wouldn't, there are a hundred bosses that would, with very little understanding of what is even being measured. Sure, the "guns don't kill people, gun users kill people" argument applies, but maybe don't hand people free guns with their milk purchase?
Oh no I agree, that was just a comment recognizing that my experience is different because I'm in a more ideal situation than other developers are surely dealing with. I still passed along the feedback to our product team!
As a "grand-boss", you may want to consider that having visibility into how an organization of a few hundred developers is spending their time is just like being a systems engineer and wanting (needing) to have monitoring of how your system load / resources are being utilized.
More often than not, I use time tracking to manage Sr Executives, and business partners, not developers. It may be invisible to most developers, but your executive probably has to fight for the budget that is funding your work on a regular basis. Having a pie chart that shows where time is spent is a great tool to convince your business partners that they can't cut everything but new feature development. It's sad how often I have to have this conversation.
Don't get me wrong, there are bad bosses, but there are many good uses of information like time tracking that may be invisible to the average developer.
More often than not, I use time tracking to manage Sr Executives, and business partners, not developers. It may be invisible to most developers, but your executive probably has to fight for the budget that is funding your work on a regular basis. Having a pie chart that shows where time is spent is a great tool to convince your business partners that they can't cut everything but new feature development. It's sad how often I have to have this conversation.
Don't get me wrong, there are bad bosses, but there are many good uses of information like time tracking that may be invisible to the average developer.
Same sentiment here. It would actually be useful if the "time tracking" supported sizing and estimations but right now it's completely focused on precise timing which makes this counter-productive.
Just making sure that you are aware that GitLab supports sizing and estimations via weights https://docs.gitlab.com/ee/user/project/issues/issue_weight....
I still think it would be useful to specify an 95th percentile error value for time estimates. I told my PM that the estimate in jira has an error range once and she flipped. Having that idea backed up by the tools we use would really help planning be more realistic.
That is a great suggestion. GitLab has burn-down charts https://docs.gitlab.com/ee/user/project/milestones/burndown_... that show that progress isn't linear.
What is small change we can make to stress planning has error bands without affecting the usability?
What is small change we can make to stress planning has error bands without affecting the usability?
From my professor:
>Consider this. What if the repository in which we craft our products is configured with cost estimates in mind? At the moment our logged hours reaches the total we projected, the repo would freeze and we grade the work. How would this affect our work?
>Do you have confidence in your plan? Would you bet your course grade on the quality of a project frozen at that point?
>Consider this. What if the repository in which we craft our products is configured with cost estimates in mind? At the moment our logged hours reaches the total we projected, the repo would freeze and we grade the work. How would this affect our work?
>Do you have confidence in your plan? Would you bet your course grade on the quality of a project frozen at that point?
> How would this affect our work?
This reminds me of the appetites and bets that Basecamp's "Shape Up" describes. https://basecamp.com/shapeup
Instead of keeping scope and time 'fixed' and sacrificing quality, instead try and keep quality and time 'fixed' but be willing to sacrifice scope.
Having an 'apetite' in mind for how much you want a particular feature then mitigates: if you fail to achieve what you want in the fixed time period, do you want to try again later or is it more effort than it's worth to you.
This reminds me of the appetites and bets that Basecamp's "Shape Up" describes. https://basecamp.com/shapeup
Instead of keeping scope and time 'fixed' and sacrificing quality, instead try and keep quality and time 'fixed' but be willing to sacrifice scope.
Having an 'apetite' in mind for how much you want a particular feature then mitigates: if you fail to achieve what you want in the fixed time period, do you want to try again later or is it more effort than it's worth to you.
I'm not a fan of time tracking as a managerial stick to keep developers "productive", but there are reasons for tracking time beyond managerial oversight. For example, in Canada accessing any of our grant programs or tax credits requires time logs as part of their reporting requirements.
Fortunately, they actually seem to prefer the reported times to be rounded to the half-hour/hour so the numbers line up with the financials. I think this helps discourage the temptation to nickel-and-dime developers over their time.
Fortunately, they actually seem to prefer the reported times to be rounded to the half-hour/hour so the numbers line up with the financials. I think this helps discourage the temptation to nickel-and-dime developers over their time.
> Development is not something you should clock in and out of.
I agree that imposing time-tracking from above (especially using user-hostile tools or especially employee-hostile management) is objectionable, BUT:
Org mode is fantastic and a great way to organize your day:
https://orgmode.org/manual/Clocking-commands.html
I agree that imposing time-tracking from above (especially using user-hostile tools or especially employee-hostile management) is objectionable, BUT:
Org mode is fantastic and a great way to organize your day:
https://orgmode.org/manual/Clocking-commands.html
Hey, also don't have a time for a full review, but had one comment. I've been a pretty passionate user of GitLab for 2+ years and really loved the industry-leading integrated CI/CD. I have found that page load times on both GitLab and GitHub, however, are pretty bad, with GitLab being the worst. Many administrative tasks, such as logging in -> finding repo -> checking a ci/cd test -> merging / releasing the branch, take 10+ page loads, and each one is quite slow. I ended up moving my personal projects to sourcehut simply because pages are more lightweight and server response times are faster. If GitLab could spend some time reducing the number of pages required for common tasks (not asking for a single-page-app!), and could reduce page load times as much as possible (I know this isn't trivial with Rails), I think that would greatly reduce the friction I feel when using the produce.
Thank you so much for the feedback! I'm asking around to see if there are any projects open to reduce the number of pages, but I do know for sure that reducing page load times is an issue we're working on. Here is our handbook page that outlines our current metrics and goals, our primary goal is to have a speed index of less than 2 seconds per each page on .com: https://about.gitlab.com/handbook/engineering/performance/
I know I'm biased here (full disclosure: sourcehut guy here), but I really hope you'll bring that goal even lower. I recently did a comparison between GitHub, GitLab, and SourceHut on the same "worst-case" page:
https://git.sr.ht/~sircmpwn/linux/tree/master/arch/arm/boot/...
https://github.com/torvalds/linux/tree/master/arch/arm/boot/...
https://gitlab.com/ddevault/linux/-/tree/master/arch/arm/boo...
https://git.sr.ht/~sircmpwn/scdoc/tree/master/src
https://github.com/ddevault/scdoc/tree/master/src
https://gitlab.com/ddevault/scdoc/-/tree/master/src
https://git.sr.ht/~sircmpwn/linux/tree/master/arch/arm/boot/...
https://github.com/torvalds/linux/tree/master/arch/arm/boot/...
https://gitlab.com/ddevault/linux/-/tree/master/arch/arm/boo...
cold cache warm cache
git.sr.ht: 1.4s 72K 1.4s 48K
github.com: 3.3s 635K 3.0s 317K*
gitlab.com: 3.1s 1300K 1.6s 58K+
* Hides half of the files
+ Only the initial load, it loads a bunch of stuff with JS to keep
populating the page afterwards, and has severe performance issues
simply using the page (on Chromium, it was straight up unusable on
qutebrowser)
https://git.sr.ht/~sircmpwn/scdoc/tree/master/src
https://github.com/ddevault/scdoc/tree/master/src
https://gitlab.com/ddevault/scdoc/-/tree/master/src
cold cache warm cache
git.sr.ht: 296ms 28K 198ms 4K
github.com: 572ms 360K 629ms 36K
gitlab.com: 1310ms 1311K 1110ms 16K
Many thanks indeed for calling this out. Performance is certainly a key goal for us and as part of the Quality group we've been increasing our performance test efforts over the last year and prioritising performance fixes with our dev teams.
We've investigated and confirmed the controller that's looks to be the cause of this and raised an Issue here - https://gitlab.com/gitlab-org/gitlab/-/issues/214681. Many thanks again.
We've investigated and confirmed the controller that's looks to be the cause of this and raised an Issue here - https://gitlab.com/gitlab-org/gitlab/-/issues/214681. Many thanks again.
I agree, thanks for the numbers. I'll suggest to incorporate this into our Q2 OKRs.
For our references please see https://storage.googleapis.com/sitespeed-results-gitlab/gitl... and https://about.gitlab.com/handbook/engineering/performance/
For our references please see https://storage.googleapis.com/sitespeed-results-gitlab/gitl... and https://about.gitlab.com/handbook/engineering/performance/
And we created https://gitlab.com/gitlab-org/gitlab/-/issues/214681
And we quickly fixed https://gitlab.com/gitlab-org/quality/performance/-/merge_re...
Great turnaround time!
Don't really have the time to do a complete write-up, but for what it's worth I've completely moved my company from GitHub to GitLab within the past year. We found the group and project hierarchy to work very well for organizing our clients and their projects, and we've made extensive use of your CI/CD.
The only real complaint I have is about the Auto DevOps feature you released. We're currently using this for a number of smaller projects, and we've found the documentation around customizing deployments severely lacking. We ended up just reading through the Auto DevOps repository since it was clearer and more complete than any online documentation, which eventually allowed us to work through all of the issues we were having.
Other than that, it has been a wonderful experience. Thanks for a great product!
The only real complaint I have is about the Auto DevOps feature you released. We're currently using this for a number of smaller projects, and we've found the documentation around customizing deployments severely lacking. We ended up just reading through the Auto DevOps repository since it was clearer and more complete than any online documentation, which eventually allowed us to work through all of the issues we were having.
Other than that, it has been a wonderful experience. Thanks for a great product!
Thanks for the feedback! It's funny you mention the Auto DevOps documentation because we just had our new senior tech writer pick up an issue [1] to completely redo it, so hopefully it'll be more intuitive soon!
[1] https://gitlab.com/gitlab-org/gitlab/-/issues/30933
[1] https://gitlab.com/gitlab-org/gitlab/-/issues/30933
The comparison states that "With GitLab, you get even more features than GitHub Team" and then lists code owners, multiple issue and PR assignees, or standard support. All these features are included in GitHub Team for $4 per month, so this whole section of the blog post is misleading.
Also, you may want to point out that GitLab only offers annual billing, so the minimum charge on GitLab is $48. Some of my hobby projects only run a couple of months, so GitHub is the better choice.
Also, you may want to point out that GitLab only offers annual billing, so the minimum charge on GitLab is $48. Some of my hobby projects only run a couple of months, so GitHub is the better choice.
Thanks for the feedback! I passed it on to our content team to see if they want to make adjustments to the blog post. I definitely don't want it to come across as misleading.
I don't have a blog to blog on yet, and you are likely looking for that to get some positive backlinks, but here are my two cents anyway.
I use both for work - and gitlab by preference:
* On the whole they are now close enough that I don't worry about the choice
* Both are slow. Silly slow. A 2 second target for page loads is horrific. Jumping around a file structure and exploring blame is really really painful; but 90% of the time I'm on the pipelines page and its so so so slow. Its actually faster for me to have my pipelines webhook a private server for a faster dash.
* GitLab is better for CI/CD. Easier, more sensible. I use it all the time; I set new clients up on it.
* Gitlab is better for k8's - several clients use it and love it.
* Search sucks on them both. They both give a paginated list when what I always want is a place in repo / filetype / etc. filter, post initial search (i.e, I'm looking for loadModule in webpack, I want to ignore tests (when I didn't know which was the test folder before searching), and jump between definition and usage, as well as find out if there is any documentation. Its not worth doing each individually. I want all at once)
* API's are really slow. GitLab is probably worse here. My default webpage (localhost home page) is a dashboard of quick links and widgets. One of those widgets shows my failing pipelines. It takes 6 seconds on a good day. I bypassed it (as above) to let me be more responsive. I didn't have to bother bypassing it w/GitHub
* On my NAS I maintain images of GitLab hosts and backups of all my repos. I have an image of the self-hosted gitlab we had at a previous (it closed) company. Being able to fall back to self-hosted is the oft-touted godsend, but being able to restart a retired self-hosted has literally made me and the others involved several thousand each (twice old clients have wanted a one off job. GitLab is the core of testing and deploying infrastructure).
I use both for work - and gitlab by preference:
* On the whole they are now close enough that I don't worry about the choice
* Both are slow. Silly slow. A 2 second target for page loads is horrific. Jumping around a file structure and exploring blame is really really painful; but 90% of the time I'm on the pipelines page and its so so so slow. Its actually faster for me to have my pipelines webhook a private server for a faster dash.
* GitLab is better for CI/CD. Easier, more sensible. I use it all the time; I set new clients up on it.
* Gitlab is better for k8's - several clients use it and love it.
* Search sucks on them both. They both give a paginated list when what I always want is a place in repo / filetype / etc. filter, post initial search (i.e, I'm looking for loadModule in webpack, I want to ignore tests (when I didn't know which was the test folder before searching), and jump between definition and usage, as well as find out if there is any documentation. Its not worth doing each individually. I want all at once)
* API's are really slow. GitLab is probably worse here. My default webpage (localhost home page) is a dashboard of quick links and widgets. One of those widgets shows my failing pipelines. It takes 6 seconds on a good day. I bypassed it (as above) to let me be more responsive. I didn't have to bother bypassing it w/GitHub
* On my NAS I maintain images of GitLab hosts and backups of all my repos. I have an image of the self-hosted gitlab we had at a previous (it closed) company. Being able to fall back to self-hosted is the oft-touted godsend, but being able to restart a retired self-hosted has literally made me and the others involved several thousand each (twice old clients have wanted a one off job. GitLab is the core of testing and deploying infrastructure).
GitLab Product Leader here -
> * Both are slow. Silly slow. A 2 second target for page loads is horrific. Jumping around a file structure and exploring blame is really really painful; but 90% of the time I'm on the pipelines page and its so so so slow. Its actually faster for me to have my pipelines webhook a private server for a faster dash.
Agreed - and we're working on performance improvements for GitLab.com. Do you use GitLab.com or a self-managed instance?
> * GitLab is better for CI/CD. Easier, more sensible. I use it all the time; I set new clients up on it.
Thanks - I'll give the feedback to the teams to keep up the good work. We do focus on sensible defaults and easy setup.
> * Gitlab is better for k8's - several clients use it and love it.
Awesome to hear, I have some heritage with this part of the product so I'm glad you love it.
> * Search sucks on them both. They both give a paginated list when what I always want is a place in repo / filetype / etc. filter, post initial search (i.e, I'm looking for loadModule in webpack, I want to ignore tests (when I didn't know which was the test folder before searching), and jump between definition and usage, as well as find out if there is any documentation. Its not worth doing each individually. I want all at once)
We have a recent integration with SourceGraph, have you tried that out? https://docs.gitlab.com/ee/integration/sourcegraph.html
> * API's are really slow. GitLab is probably worse here. My default webpage (localhost home page) is a dashboard of quick links and widgets. One of those widgets shows my failing pipelines. It takes 6 seconds on a good day. I bypassed it (as above) to let me be more responsive. I didn't have to bother bypassing it w/GitHub
Uggh - I'm sorry. I don't quite understand your reference to a default webpage and widgets. Is it pulling from GitLab APIs to give you a dashboard of your development work?
> * On my NAS I maintain images of GitLab hosts and backups of all my repos. I have an image of the self-hosted gitlab we had at a previous (it closed) company. Being able to fall back to self-hosted is the oft-touted godsend, but being able to restart a retired self-hosted has literally made me and the others involved several thousand each (twice old clients have wanted a one off job. GitLab is the core of testing and deploying infrastructure).
I didn't follow this one explicitly either. I'm glad you've got backups, are you suggesting GitLab needs some improved restore capabilities from backups?
> * Both are slow. Silly slow. A 2 second target for page loads is horrific. Jumping around a file structure and exploring blame is really really painful; but 90% of the time I'm on the pipelines page and its so so so slow. Its actually faster for me to have my pipelines webhook a private server for a faster dash.
Agreed - and we're working on performance improvements for GitLab.com. Do you use GitLab.com or a self-managed instance?
> * GitLab is better for CI/CD. Easier, more sensible. I use it all the time; I set new clients up on it.
Thanks - I'll give the feedback to the teams to keep up the good work. We do focus on sensible defaults and easy setup.
> * Gitlab is better for k8's - several clients use it and love it.
Awesome to hear, I have some heritage with this part of the product so I'm glad you love it.
> * Search sucks on them both. They both give a paginated list when what I always want is a place in repo / filetype / etc. filter, post initial search (i.e, I'm looking for loadModule in webpack, I want to ignore tests (when I didn't know which was the test folder before searching), and jump between definition and usage, as well as find out if there is any documentation. Its not worth doing each individually. I want all at once)
We have a recent integration with SourceGraph, have you tried that out? https://docs.gitlab.com/ee/integration/sourcegraph.html
> * API's are really slow. GitLab is probably worse here. My default webpage (localhost home page) is a dashboard of quick links and widgets. One of those widgets shows my failing pipelines. It takes 6 seconds on a good day. I bypassed it (as above) to let me be more responsive. I didn't have to bother bypassing it w/GitHub
Uggh - I'm sorry. I don't quite understand your reference to a default webpage and widgets. Is it pulling from GitLab APIs to give you a dashboard of your development work?
> * On my NAS I maintain images of GitLab hosts and backups of all my repos. I have an image of the self-hosted gitlab we had at a previous (it closed) company. Being able to fall back to self-hosted is the oft-touted godsend, but being able to restart a retired self-hosted has literally made me and the others involved several thousand each (twice old clients have wanted a one off job. GitLab is the core of testing and deploying infrastructure).
I didn't follow this one explicitly either. I'm glad you've got backups, are you suggesting GitLab needs some improved restore capabilities from backups?
I'm using GitLab.com (unless working with a client that uses an on-prem).
Yes, I mean I'm using the API, specifically the graphQL one because it was giving detail of pipelines better.
The last NAS/backups, I'm saying GitLab is better because it allows me to not be reliant on the ongoing subscription due to the on-prem / community edition (backing up the git repos is only half the story for a functional system).
Yes, I mean I'm using the API, specifically the graphQL one because it was giving detail of pipelines better.
The last NAS/backups, I'm saying GitLab is better because it allows me to not be reliant on the ongoing subscription due to the on-prem / community edition (backing up the git repos is only half the story for a functional system).
I've wanted to do a deep dive into Github vs Gitlab for projects. But I'm a bit hesitant to have that on my blog. Unfortunately most places I've been pushing for anything other than Github is not well received.
That being said I've been using GitLab for a several years.
Right now is a perfect example of why I use GitLab. I just started a role, and I'm working to improving pull request and CI/CD visibility. This is automatically baked into GitLab. To the point I just copy a template for all my projects. But now I'm writing a bunch of custom integrations, and talking to a number of different third party services. Even with all the extra work it feels less polished than GitLab.
With Kubernetes, Serverless, and prometheus metrics integration. Gitlab hand's down provides the best visibility into a release or sprint from what I've seen. There are pain points, but I have very little in the way of complaints.
You guys have also been great for the open source community. I got a Gold open source license and am using it for a number of projects.
I've converted a number of people to GitLab, now we just need to find places that will let us use it.
That being said I've been using GitLab for a several years.
Right now is a perfect example of why I use GitLab. I just started a role, and I'm working to improving pull request and CI/CD visibility. This is automatically baked into GitLab. To the point I just copy a template for all my projects. But now I'm writing a bunch of custom integrations, and talking to a number of different third party services. Even with all the extra work it feels less polished than GitLab.
With Kubernetes, Serverless, and prometheus metrics integration. Gitlab hand's down provides the best visibility into a release or sprint from what I've seen. There are pain points, but I have very little in the way of complaints.
You guys have also been great for the open source community. I got a Gold open source license and am using it for a number of projects.
I've converted a number of people to GitLab, now we just need to find places that will let us use it.
It's great to hear you've had a good experience with the GitLab for Open Source Gold license. I'm the new Sr. Open Source Program Manager at GitLab and I'm helping to revamp the program and also want to find new ways to make GitLab even more value for open source projects and orgs.
As a program manager, I'm personally really excited about this year's plans to build out more of GitLab's project management features. I think that once we're able to be more competitive with tools like Jira it will help create more buy-in at companies to adopt a single platform. Let's hope!
Thank you for advocating for GitLab among your spheres of influence, and for being part of the GitLab community! We appreciate it!
As a program manager, I'm personally really excited about this year's plans to build out more of GitLab's project management features. I think that once we're able to be more competitive with tools like Jira it will help create more buy-in at companies to adopt a single platform. Let's hope!
Thank you for advocating for GitLab among your spheres of influence, and for being part of the GitLab community! We appreciate it!
Doing a campaign/survey where you pay people to compare yourself to your direct competition on your blog, on the areas you chose? Really objective.
Also, this topic is about the article linked, not about your survey.
As feedback, I would say Github is a better company since it doesn't sink this low on their tactics. They just focus on making their product better.
Also, this topic is about the article linked, not about your survey.
As feedback, I would say Github is a better company since it doesn't sink this low on their tactics. They just focus on making their product better.
Several people have already mentioned that gitlab is slow, so very slow. I've seen replies in this thread that make it obvious that this is being tracked, and that you're well-aware of it.
That said I can't help recalling the last time the topic came up, seven months ago even then it was old-news:
https://news.ycombinator.com/item?id=20995889
If the site hasn't gotten faster in the past year I think it is obvious that this is not a priority in any real sense. Despite claims to the contrary.
Gitlab has a great core-offering, the gitlab runners were wonderful when they came out. But it seems like new features are constantly being piled on top of each release, (time tracking?!) when it might benefit users to step back a little bit and focus upon the core.
I can only assume developers get recognition by new-features, not core-improvements.
That said I can't help recalling the last time the topic came up, seven months ago even then it was old-news:
https://news.ycombinator.com/item?id=20995889
If the site hasn't gotten faster in the past year I think it is obvious that this is not a priority in any real sense. Despite claims to the contrary.
Gitlab has a great core-offering, the gitlab runners were wonderful when they came out. But it seems like new features are constantly being piled on top of each release, (time tracking?!) when it might benefit users to step back a little bit and focus upon the core.
I can only assume developers get recognition by new-features, not core-improvements.
Thanks, I agree we should focus more on loading speed and we'll do so in our second fiscal quarter that starts in two weeks https://about.gitlab.com/company/okrs/fy21-q2/
The comment you linked says: "We are working hard to improve performance and memory consumption of GitLab. We have two major projects underway, switching to Puma [1] as well as reducing the overall memory consumption of GitLab [2]."
The current state is that Puma is now powering all of GitLab.com and we're working on getting it to be the default in Omnibus https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4698
The comment you linked says: "We are working hard to improve performance and memory consumption of GitLab. We have two major projects underway, switching to Puma [1] as well as reducing the overall memory consumption of GitLab [2]."
The current state is that Puma is now powering all of GitLab.com and we're working on getting it to be the default in Omnibus https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4698
When will GitLab release the issue edit history feature? It's a very important feature for every group
Community advocate here, this released in GitLab 12.9 version
https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-rel... https://gitlab.com/gitlab-org/gitlab/issues/32894
Here's the documentation: https://docs.gitlab.com/ee/user/project/issues/issue_data_an...
https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-rel... https://gitlab.com/gitlab-org/gitlab/issues/32894
Here's the documentation: https://docs.gitlab.com/ee/user/project/issues/issue_data_an...
Is it possible to submit replies via Fediverse or mail? Asking since I do not have a Twitter account and do not want to create one.
Competition is good for the end user, but ISTM that Microsoft bought the biggest player in the space so that they could drown the competition in the bathtub and monopolize the market. It's a smart play from Microsoft's point of view, but FTC should never have permitted the acquisition in the first place and should prosecute them for illegal dumping now.
Github and Gitlab are not so important to any market as to warrant federal intervention. Both of them are easily replaced by anyone standing up their own git server. Not to mention the countless other code repository sites / software packages.
Moving of isn't easy
- thanks to GitHub pages and markdown rendering your tool's homepage is the Git{Hub|Lab|...} page. That page is linked from "everywhere" else and indexed in search engines
- all history aside from code is in there (discussions in bug issues and pull requests etc.) getting them out is possible, but all the linkage between commit messages and those might be problematic to migrate
- contributors are often only known by their handle on that page, migrating of requires new setup of permissions and mapping of usernames to trust on a social level
- there are tons of hooks configured for many projects
- as GitHub Actions and GitLab CI gain more and more traction workflows depend on those
"Just move the repo" is a fallancy which doesn't work. I have no doubts medium term about Microsoft steering GitHub, but I fear a single entity being so central in the opensoruce world (also consider npm acquisition etc.)
- thanks to GitHub pages and markdown rendering your tool's homepage is the Git{Hub|Lab|...} page. That page is linked from "everywhere" else and indexed in search engines
- all history aside from code is in there (discussions in bug issues and pull requests etc.) getting them out is possible, but all the linkage between commit messages and those might be problematic to migrate
- contributors are often only known by their handle on that page, migrating of requires new setup of permissions and mapping of usernames to trust on a social level
- there are tons of hooks configured for many projects
- as GitHub Actions and GitLab CI gain more and more traction workflows depend on those
"Just move the repo" is a fallancy which doesn't work. I have no doubts medium term about Microsoft steering GitHub, but I fear a single entity being so central in the opensoruce world (also consider npm acquisition etc.)
I disagree. Github and Gitlab are so much more than just code hosting platforms. Their ability to influence software development is increasing to the point that if both Github and Gitlab suddenly disappear the consequences would be quite dramatic.
Wow, a true HN “I could do that in a weekend”. Good point, all software is trivial and anyone could recreate a website with thousands of man hours behind them in a long weekend.
Are we suddenly pretending that Redmine and others don't exist for self hosting?
Yes, there are lots of options in the space, but no one wants to use an option that is 75% as good as Github and still costs more. The only way to gain marketshare is to either get bundled into an enterprise contract (so it doesn't matter if you suck) or be better than Github and still underprice your product. Even Google gave up on their code hosting option because there's no way to get market share without setting money on fire. God bless Gitlab, but if Microsoft keeps supporting Github like this (and the FTC keeps taking long naps), they're going to run out money and die.
The only one important (imho of course) feature that GitHub has and self-hosted GitLab lacks is search across repositories [0]. Search inside a single repository is done via git.
Of course you can self-host and configure your own Sourgraph installation, but that's a bit more work.
[0] https://forum.gitlab.com/t/search-code-across-all-projects/2...
Of course you can self-host and configure your own Sourgraph installation, but that's a bit more work.
[0] https://forum.gitlab.com/t/search-code-across-all-projects/2...
For self-hosted instances you can use Advanced Global Search https://docs.gitlab.com/ee/user/search/advanced_global_searc... to do this. Please note that this requires installation of Elastic Search. It used to be a paid feature but I think we recently open sourced it.
I love the Gitlab CI. It’s so easy to create a new project, and the CI is ready to go. No fumbling around, and the integration is great with the Gitlab docker image store.
It is great, except there STILL is no reasonable way of finding a particular image in the registry. You can't order by date uploaded! Only by name. Which means the order is out of whack as soon as you go from version 9 to version 10.
And to make it worse, paging is extremely slow, so it could take an hour of paging into the middle of the list to find the name of the image you're looking for. Even if the image was uploaded 1 minute ago it could be in the middle page.
Thankfully I don't have to do this very often, but it's a horrible experience when needed.
For similar reasons deleting unneeded images takes forever and is not feasible.
And to make it worse, paging is extremely slow, so it could take an hour of paging into the middle of the list to find the name of the image you're looking for. Even if the image was uploaded 1 minute ago it could be in the middle page.
Thankfully I don't have to do this very often, but it's a horrible experience when needed.
For similar reasons deleting unneeded images takes forever and is not feasible.
Hmm good point about that. I’ve never really had maybe more than 5 so it hasn’t been an issue. The auto pruning is a pain too.
I want to second this. I use GitLab for personal projects and have used their CI extensively.
My work uses Github and has all the repos hosted there. I tried to start using Github Actions (or whatever it is called?) about a month ago, and just couldn't make sense of it.. does it provision servers from Docker images/docker-compose files? or is it only a "carcass" where I have to add an additional server? can I do everything "as code" or do I have to mingle with the web console ?
After spending about 2 hours tinkering I gave up.
My work uses Github and has all the repos hosted there. I tried to start using Github Actions (or whatever it is called?) about a month ago, and just couldn't make sense of it.. does it provision servers from Docker images/docker-compose files? or is it only a "carcass" where I have to add an additional server? can I do everything "as code" or do I have to mingle with the web console ?
After spending about 2 hours tinkering I gave up.
Really? I was able to throw together an entire CI/CD workflow in Github that builds, tests, measures coverage and deploys to GCE in like 30 minutes. Bringing your own agents looks fairly simple too and follows a GitOps model:
https://help.github.com/en/actions/hosting-your-own-runners
https://help.github.com/en/actions/hosting-your-own-runners
It's weird how the article looks at the true reason right there and then just chooses ignores it.
Microsoft bought Github in part to get developer mindshare, just like VSCode, and WSL, and a ton of other great efforts have.
They literally quote Nadella saying this on an earnings call!
If Occam's razor and the money line up, why does this have to be some secret attempt to beat Gitlab?
Microsoft bought Github in part to get developer mindshare, just like VSCode, and WSL, and a ton of other great efforts have.
They literally quote Nadella saying this on an earnings call!
If Occam's razor and the money line up, why does this have to be some secret attempt to beat Gitlab?
Open source .NET, SQL server running on Linux, VS Code, Github, NPM, WSL, tons of opensource on Azure.
I think you are right, and Microsoft is after winning developers, not fighting with Gitlab.
I think this is a winning strategy and we will see even more moves in this direction. Probably more acquisitions, more open sourcing products, more free stuff, more cross platform tools targeted at developers.
A developer by himself doesn't have much decision power, but if more developers prefer something, companies will follow and use Microsoft's products.
I think you are right, and Microsoft is after winning developers, not fighting with Gitlab.
I think this is a winning strategy and we will see even more moves in this direction. Probably more acquisitions, more open sourcing products, more free stuff, more cross platform tools targeted at developers.
A developer by himself doesn't have much decision power, but if more developers prefer something, companies will follow and use Microsoft's products.
Developer mindshare. Mindshare at all.
Compare to Oracle. When Sun had been trying to win mindshare with OpenSolaris, what did Oracle do? It killed it. It also effectively killed any chance of winning that mindshare. I'm still salty about that.
Open source is a business tool. A tool for building trust and mindshare.
Compare to Oracle. When Sun had been trying to win mindshare with OpenSolaris, what did Oracle do? It killed it. It also effectively killed any chance of winning that mindshare. I'm still salty about that.
Open source is a business tool. A tool for building trust and mindshare.
Yeah, Apple, Google, Amazon - the usual culprits - are the competition, not small fish like GitLab.
Turns out competition is good for end users.
As long as VCs fuel GL to stay alive against Microsoft's pockets (Microsoft benefits from it in multiple ways even if GitHub isn't profitable, GitLab has no other revenue stream)
[deleted]
My small org will be moving back to GitHub. While GitLab is a fantastic product, we have been looking for a low cost global search ability, and well, you can't argue with _free_.
Interesting that you'll risk moving your dev ops workflow because of a single feature that GitHub doesn't even do well.
we utilize other systems for this (not great, but works). for the type of work we do, global search is a huge win over other potential trade offs.
The blog post mentions that you recently open sourced 18 features that were previously paid. I assume that refers to this announcement: https://about.gitlab.com/blog/2020/03/30/new-features-to-cor....
It seems those are proposals (or at best commitments) for things to be open sourced in future versions rather than things that actually are available as open source already? Could you clarify please?
It seems those are proposals (or at best commitments) for things to be open sourced in future versions rather than things that actually are available as open source already? Could you clarify please?
GitLab Developer Evangelist here.
They are commitments. Each feature has its own issue for the engineering effort behind moving it to Core with various milestones based on team capacity and complexity of the move.
You can track each with the table in the post that relates the feature to “GitLab issue” that represents the move.
They are commitments. Each feature has its own issue for the engineering effort behind moving it to Core with various milestones based on team capacity and complexity of the move.
You can track each with the table in the post that relates the feature to “GitLab issue” that represents the move.
Fair enough. Don't get me wrong I'm very excited about the announcement and think it'll be great to have some of these features in the open source core, I just thought it was a little misleadingly worded in this blog post. Seemed to imply the work had already been done.
GitLab PM here for the Package stage. We announced that the Package Registry offering will be included in GitLab Core.
This means that for npm, Maven, NuGet, Conan and any future formats, you will be able to:
- Establish GitLab as a private repository - Authenticate using your GitLab credentials, personal access or job token - Publish packages to GitLab - Pull packages from GitLab - Search for packages hosted on GitLab - Access an easy-to-use UI that displays package details and metadata and allows you to download any relevant files
It does take a bit of work to migrate the code. We are currently investigating what work is required and will have a better sense of timing once the investigation is complete. We are hoping to have this complete in the next few months.
You can follow along in the issue here: https://gitlab.com/groups/gitlab-org/-/epics/2867.
This means that for npm, Maven, NuGet, Conan and any future formats, you will be able to:
- Establish GitLab as a private repository - Authenticate using your GitLab credentials, personal access or job token - Publish packages to GitLab - Pull packages from GitLab - Search for packages hosted on GitLab - Access an easy-to-use UI that displays package details and metadata and allows you to download any relevant files
It does take a bit of work to migrate the code. We are currently investigating what work is required and will have a better sense of timing once the investigation is complete. We are hoping to have this complete in the next few months.
You can follow along in the issue here: https://gitlab.com/groups/gitlab-org/-/epics/2867.
I used GitLab for years. That changed a few months ago. I deleted my account and now use GitHub. I advocate everywhere I can to choose GitHub over GitLab, or to migrate away from GitLab if it's already in use. These changes just make me more convinced that GitLab is on a path to oblivion.
I put up with GitLab's slow interface, relatively poor UX, and relative lack of community because I wanted a trustworthy product that respected the privacy and security of my critical tooling and to support a company with a benign business model.
After the tracking debacle a few months ago, it became clear to me that GitLab isn't trustworthy. They're looking for an acquisition, maybe an IPO, and exploiting users (and even on-prem customers!) is clearly going to be part of that game plan.
So why stick with the crappier alternative? If I'm getting sold out either way, I might as well use the superior product.
Maybe I could be convinced to switch back, though. @sytse did you fire Paul Machle yet? If not, then obviously Paul was merely taking the heat for doing what you want, and there is just no way I can ever trust GitLab.
EDIT: Nope, looks like that goober is still the CFO: https://gitlab.com/pmachle . Oh well, bye bye GitLab! I hope you die and make some more room for SourceHut. :)
I put up with GitLab's slow interface, relatively poor UX, and relative lack of community because I wanted a trustworthy product that respected the privacy and security of my critical tooling and to support a company with a benign business model.
After the tracking debacle a few months ago, it became clear to me that GitLab isn't trustworthy. They're looking for an acquisition, maybe an IPO, and exploiting users (and even on-prem customers!) is clearly going to be part of that game plan.
So why stick with the crappier alternative? If I'm getting sold out either way, I might as well use the superior product.
Maybe I could be convinced to switch back, though. @sytse did you fire Paul Machle yet? If not, then obviously Paul was merely taking the heat for doing what you want, and there is just no way I can ever trust GitLab.
EDIT: Nope, looks like that goober is still the CFO: https://gitlab.com/pmachle . Oh well, bye bye GitLab! I hope you die and make some more room for SourceHut. :)
>They're looking for an acquisition, maybe an IPO, and exploiting users (and even on-prem customers!) is clearly going to be part of that game plan.
Could you elaborate?
In what way are you aware that Gitlab is:
- seeking acquisition (makes sense that they would, I am just seeking some evidence to confirm the suspicion). To be fair, a large part of why I use GitLab is because it is not owned by Microsoft. Hence I am interested in whether or not GitLab will stay independent or "sell out". Certainly I'd lean on the latter, but again, seeking evidence of any planning on their part to seek acquisition.
- exploiting users (or how it would be part of the "game plan" -- I can see exploiting user data they've gathered while users use their free service... but that's capitalism. Is there any other way they currently or might in the future exploit users?)
Could you elaborate?
In what way are you aware that Gitlab is:
- seeking acquisition (makes sense that they would, I am just seeking some evidence to confirm the suspicion). To be fair, a large part of why I use GitLab is because it is not owned by Microsoft. Hence I am interested in whether or not GitLab will stay independent or "sell out". Certainly I'd lean on the latter, but again, seeking evidence of any planning on their part to seek acquisition.
- exploiting users (or how it would be part of the "game plan" -- I can see exploiting user data they've gathered while users use their free service... but that's capitalism. Is there any other way they currently or might in the future exploit users?)
I have no hard evidence that they are actually actively seeking a buyout/IPO, but they did complete a Series E last year[0] led by Goldman Sachs and IONIQ Capital. Presumably their numerous investors will be looking for a solid return, either through an acquisition or IPO.
WRT how they might exploit users, it's not really so much that there are specific ways I worry they will exploit users--well, I guess I am specifically worried they will once again hold private repos for ransom until you agree to some abusive new terms. It's perhaps best summarized with an infamous quote about user tracking from GitLab CFO Paul Machle:
> I don’t understand. This should not be an opt in or an opt out. It is a condition of using our product. There is an acceptance of terms and the use of this data should be included in that.
In other words, "Fuck the users, it's our product. Hold their repos for ransom until they agree." Which they in fact did for a short time until the PR blowback became unbearable. This was supposed to apply to self-hosted GitLab EE, too, BTW.
The fact that Paul survived that very public middle finger to users and the security of the product and remains CFO shows that Sytse agrees with his philosophy, even if he isn't as brazen about it. The kind of money Sytse presumably has made and especially stands to make in a successful exit tends to have a peculiar effect on people, so perhaps it's not surprising...
If you continue to use GitLab, be prepared: Make sure you have a replica of all the content (including issues etc.) you might need in the future. You just don't know how or when they're going to screw you over next, but you can be sure it'll happen.
[0]: https://www.crunchbase.com/funding_round/gitlab-com-series-e...
WRT how they might exploit users, it's not really so much that there are specific ways I worry they will exploit users--well, I guess I am specifically worried they will once again hold private repos for ransom until you agree to some abusive new terms. It's perhaps best summarized with an infamous quote about user tracking from GitLab CFO Paul Machle:
> I don’t understand. This should not be an opt in or an opt out. It is a condition of using our product. There is an acceptance of terms and the use of this data should be included in that.
In other words, "Fuck the users, it's our product. Hold their repos for ransom until they agree." Which they in fact did for a short time until the PR blowback became unbearable. This was supposed to apply to self-hosted GitLab EE, too, BTW.
The fact that Paul survived that very public middle finger to users and the security of the product and remains CFO shows that Sytse agrees with his philosophy, even if he isn't as brazen about it. The kind of money Sytse presumably has made and especially stands to make in a successful exit tends to have a peculiar effect on people, so perhaps it's not surprising...
If you continue to use GitLab, be prepared: Make sure you have a replica of all the content (including issues etc.) you might need in the future. You just don't know how or when they're going to screw you over next, but you can be sure it'll happen.
[0]: https://www.crunchbase.com/funding_round/gitlab-com-series-e...
Good to know. Thanks for sharing.
Well, this definitely makes me think that it's best if I self-host my git repos starting at some point in the near future.
Well, this definitely makes me think that it's best if I self-host my git repos starting at some point in the near future.
Is anyone working on an alternative to NPM?
GitLab Developer Evangelist here.
You can host NPM registries in your GitLab projects. https://docs.gitlab.com/ee/user/packages/npm_registry/
Moving to Core (free AND open source) soon along with 17 other features: https://about.gitlab.com/blog/2020/03/30/new-features-to-cor...
You can host NPM registries in your GitLab projects. https://docs.gitlab.com/ee/user/packages/npm_registry/
Moving to Core (free AND open source) soon along with 17 other features: https://about.gitlab.com/blog/2020/03/30/new-features-to-cor...
Here's one recent attempt:
https://github.com/braydonf/gpk
People celebrate as monopoly abuses power to further dominate the market
Altho it's still in preview, is Jetbrains Spaces essentially the same thing as GitLab?
It definitely looks like to be a competitor
GitHub was better even without these features than GitLab tho. GitLab UI is slow and un-intuitive.
Hey! GitLab employee here. The speed of the site has been on our radar too, we have a handbook page [1] detailing our metrics and our goals. Ultimately we want to have a speed index of less than 2 seconds for .com, but we know we aren't quite there yet.
As for the UI being unintuitive, I'm sorry to hear that. Everyone has different UI preferences so it's understandable. If you want, we're holding a competition right now [2] for anyone who writes a review of GitLab vs GitHub if there are any specific features within GitHub's UI that you like better!
[1] https://about.gitlab.com/handbook/engineering/performance/
[2] https://about.gitlab.com/blog/2020/04/14/github-free-for-tea...
As for the UI being unintuitive, I'm sorry to hear that. Everyone has different UI preferences so it's understandable. If you want, we're holding a competition right now [2] for anyone who writes a review of GitLab vs GitHub if there are any specific features within GitHub's UI that you like better!
[1] https://about.gitlab.com/handbook/engineering/performance/
[2] https://about.gitlab.com/blog/2020/04/14/github-free-for-tea...
I fail to see how Gitlab's UI is not intuitive, for the most part 90% of the GitHub functionality is in 3 menus.
It does get complicated when you start adding kubernetes clusters and more of the Gitlab gold features, but even then I think its well managed.
As far as speed goes, it is slower than GitHub, but has gotten a lot better over the last year. Just browsing around right now it loads within 1 second for pretty much anything besides pull requests.
It does get complicated when you start adding kubernetes clusters and more of the Gitlab gold features, but even then I think its well managed.
As far as speed goes, it is slower than GitHub, but has gotten a lot better over the last year. Just browsing around right now it loads within 1 second for pretty much anything besides pull requests.
> As far as speed goes, it is slower than GitHub, but has gotten a lot better over the last year. Just browsing around right now it loads within 1 second for pretty much anything besides pull requests.
And that goes down even further when self-hosting. We're hosting ours (700+ projects, a dozen active users, 40GB worth of repos, and a half dozen active CI Runners) on a $80 Linode with a dozen other internal services that are constantly being used and we see 400-700ms loads on most pages. The performance is fantastic, frankly. And the CI/CD is the best I've used (comparing against Jenkins, Bamboo, Travis, and Circle)
And that goes down even further when self-hosting. We're hosting ours (700+ projects, a dozen active users, 40GB worth of repos, and a half dozen active CI Runners) on a $80 Linode with a dozen other internal services that are constantly being used and we see 400-700ms loads on most pages. The performance is fantastic, frankly. And the CI/CD is the best I've used (comparing against Jenkins, Bamboo, Travis, and Circle)
I do not understand this kind of brand loyalty.
Even if you're not interested in using Gitlab yourself, the competition and user migrations are clearly turning Github into a better service. You benefit from Microsoft's need to court those users, even if you never touch Gitlab.
Just take the newly reduced prices and free features in your favorite service and be happy.
Even if you're not interested in using Gitlab yourself, the competition and user migrations are clearly turning Github into a better service. You benefit from Microsoft's need to court those users, even if you never touch Gitlab.
Just take the newly reduced prices and free features in your favorite service and be happy.
> I do not understand this kind of brand loyalty.
What are you on about? They didn't mention any loyalty to a brand. They said qualitatively what they preferred about one product to another.
What are you on about? They didn't mention any loyalty to a brand. They said qualitatively what they preferred about one product to another.
Not sure how saying "This one product is better than the other" is brand loyalty...
I mean, they could have added "in my opinion", but I don't think it's too hard to assume they're referring to their opinion and not unilaterally declaring their word as law?
I mean, they could have added "in my opinion", but I don't think it's too hard to assume they're referring to their opinion and not unilaterally declaring their word as law?
I am not loyal to GitHub at all, I was very excited and one of first users of GitLab, the CI component was amazing.
I am just saying things like it is.
I am just saying things like it is.
No it wasn't. Gitlab CI is such a great thing and well integrated with the main product. Github is nowhere near.
Another thing is better branch protection, more granular branch merging and review policies.
That's just from the top of my head.
Another thing is better branch protection, more granular branch merging and review policies.
That's just from the top of my head.
sytse (GitLab CEO) and natfriedman (GitHub CEO) are curiously missing from the thread.
I was doing iteration office hours https://www.youtube.com/watch?v=u5e-6R5NWl0 :)
The thread is 1 hour old.
Well since GitLab and GitHub clearly have a long running PR war on HN (ie these posts are planned and scheduled), this doesn't seem like much of an answer ...
This article is published by a third party, and posted by a different third party.
https://about.gitlab.com/blog/2020/04/14/github-free-for-tea...