Hacker News Reader

Comment by emilycook | Hacker News Reader

GitLab community advocate here! I wanted to let everyone know about a challenge we're holding right now. If you send us your review of GitLab vs GitHub (whether positive/negative/neutral), we'll send you some swag. We know competition is good for end-users, so now it's our turn to evaluate what we're doing right and what we can improve upon.

https://about.gitlab.com/blog/2020/04/14/github-free-for-tea...

View on HN

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.

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?

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!

I think time tracking in GitLab originated as a way to track time if you're working for multiple clients, but I'm not sure.

This is what I use it for.

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?

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?

> 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.

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.

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.

> 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

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...

                    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)

Even after the page loads, for me it's impossible to use. On a more forgiving "best-case" page, GitLab has poor performance:

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

You should definitely make performance a core focus IMO.

Oh my goodness thank you so much for this! I'm gonna show this to our performance team. I appreciate you sharing the comparison, this is very helpful.

No problem. Good luck bringing these numbers down!

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/

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!

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.

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!

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

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.

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).

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?

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).

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.

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!

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.

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.

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

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...

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.

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.

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.)

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.

Reply on news.ycombinator.com