As far as the frequent upgrades go, we've been using .com as a way of dogfooding GitLab at scale. Sometimes this goes well and other times it doesn't. We're actively working to improve this process so that downtime and breaking changes are less frequent. The end goal is to eradicate both issues so that upgrades are seamless.
@Perihelion: Allow me to be the one who says "thanks for your efforts" and "keep up the good work".
My team are using GitLab to manage development and we're happy with how it's going so far.
Whats up with that?
Simplicity. Ruby on Rails facilitates that approach, for example.
> And in that case should the Content-Type (or Accepts) be the main factor?
Content-Type, yup! Unfortunately Chrome and IE 10 (not sure about Edge) disagree on that.
Without the Vary header, the back button leads to rendering what the server last returned, without taking the Content-Type into account - which is completely nonsensical in my opinion.
Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=94369
Repo and page that demonstrate the issue: https://github.com/guilhermesimoes/chrome-bug
This has been going on since at least 2011 so it seems nobody cares.
I honestly do not understand why that Vary header is necessary.
Firefox doesn't seem to need it to render pages from its cache correctly.
> History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.
Doesn't matter whether a Vary header is sent or not; when a user clicks the back button they should see exactly what they saw when they previously viewed that page; regardless of whether that content is cached or not.
Why the X-Requested-With should be in Vary when the same client did the request? (Yes, I see, Ajax libs populate this field, whereas usual browser navigation doesn't. Makes no sense.)
Why is that resource in cache anyhow, when it should be Cache-Control: no-cache (or at least must-revalidate, but it probably is, but of course that again means that the cache returns the JSON after getting the 304 from the backend, because it doesn't differentiate between responses with different Content-Type)?
It seems to me that the X-Requested-With is again a hack on top of "representational state transfer", because it was easier than trying to use Content-Type.
Because they are the same underlying thing...
I mean, I know RoR likes magic very much, but it's not totally surprising to separate the backend from the frontend.
And then use a SPA framework and use Ajax to communicate with the backend via a "REST API", because that simplifies the backend. A lot. You don't have to have views, templates, and so on implemented.
So either the REST API is not a REST API, but a lot of interesting endpoints for the frontend dynamic JS magic, or the frontend is not a frontend, just a lot of glitter thrown up on a REST API.
(I quickly tried to get something in JSON from a GitLab URL, but I just get a HTTP 406. :( )
As someone who hacks on a SaaS with a sprawling feature set which ships often, I understand where you're coming from. But I would recommend giving things like that some thought.
A sign of the future. As browser march headlong into being app platforms instead of browsers expect the back button to disappear entirely.
no it isn't?
Not at all.
Some gripes:
- Bad UX, just one example: many things that require one-click + type in competetitors products require more than one click (2-3). Another: Hard to see in the issue tracker which issues were updated.
- Bad notifications: It seriously creates notifications for actions done by oneself. That makes absolutely no sense at all whatsoever.
- Somewhat sluggish performance .... compared to Github!
- Poor review UX
- Annoyingly bad issue listings (e.g. select some issues and change something about them)
... and I've literally only used it in one rather small project. Incidentally no one of the regular users I know are satisfied or ok with Gitlab.
- We're working on improving the UX. Issue filters allow you to type now. UX team work can be seen in https://docs.google.com/presentation/d/163xL_FLQLsWD8Yv9GfkR... and https://www.youtube.com/watch?v=NtDzyHnedoE The UX research in https://docs.google.com/presentation/d/1ZE9BNAnIPDKxgSyQU5su... and https://www.youtube.com/watch?v=k8-Jto8FTmA Sorry for the general answer, I can't be more specific since I don't know what flow you mean.
- As mentioned in https://news.ycombinator.com/item?id=14354087 some people like getting their own notifications, but maybe we should make it configurable.
- GitLab.com is slow compared to GitHub.com, we're working on this in https://gitlab.com/gitlab-com/infrastructure/issues/947 The GNOME team is looking to self host so they don't have this problem.
- What is the nr. 1 thing you would improve in the review UX? I'm excited about https://gitlab.com/gitlab-org/gitlab-ee/issues/1984
- I think mass updates to issues are getting some love in https://gitlab.com/gitlab-org/gitlab-ce/issues/28340
Ironically I wish this feature existed on Github (does it???). To be more specific, I wish I could get emailed when I make comments on PRs. As crazy as it sounds, it is much easier for me to track whether the comments have been addressed in a list of emails instead of trying to dig through Github's comment interface after I've made many different comments.
Of course this wouldn't be necessary if that compact list just existed in Github already...
- Go to https://github.com/settings/notifications
- Check "Email" under Watching
- Then check "Include your own updates" in the section below
It's extremely useful to be able to read whole threads on email when you have a potent MUA.
I completely agree. I only use it because it has a CI for private projects for free but that's literally the only reason. The UX is not great (Github PRs are light years ahead of Gitlab merge requests), the overall UI is confusing and is hard to find stuff you want to, it is still extremely slow and lots of downtimes. They have some good ideas but the execution is usually not great.
The only 2 selling points are the free CI and the fact that is open-source but overall I think Gitlab wouldn't be a hard competitor to beat for newcomers.
I would love to know more about your thoughts on this statement ;) in order to get to actionable issues on which we can improve!
- Can see new stuff that happened since the last time I was on the PR
- Review mode
- Faster
- Can view rendered file (like .md) without leaving the page
- Commits visible on the main tab
And for a more subjective one: the gitlab feels extremely crowded and a general lack of polish.
Take the right sidebar on a merge request for examples, they are icons since it is hidden by default even in full screen. Hovering on the + shows a Add Todo dialog but hovering over any other icon does nothing. I had to click to see what the watch and stopwatch were. In general, I wasn't able to guess what any of the icons were, except for the labels icon. On the other hand, Github doesn't use icons: just a bunch of text which is imo nicer in terms of design and more user friendly.
Thanks for leaving some feedback.
* Speed
GNOME is looking to self-host their own GitLab CE instance. We understand that GitLab.com might have some performance issues. This is specific to our hosted GitLab instance due to its scale. A self-hosted instance on a much smaller scale is much much faster.
Also, we're always looking to improve GitLab performance - check out issues labeled "performance" in the GitLab CE repo [1] as well as issues in the infrastructure repo which are about .com specifically [2]
* Commits visible on the main tab
A list of commits is just a click away in the MR view, in the "Commits" tab. Also commits that are added are also displayed in the main tab.
* Can see new stuff that happened
The main MR tab lists the actions that happened related to it in a chronological order, from first to last. You can always look at that and see any new MR changes
* Sidebar
The sidebar is expanded by default on larger screen sizes and collapsed on smaller ones to preserve screen real estate for the MR itself.
I opened an issue about the icons themselves, see [3]
* View rendered files in MR
We have renderers for all kinds of files. But in a MR, we diff the MD source files. If we rendered them, diffing them would be almost impossible.
I opened an issue about having toggle-able rendering in the changes tab in MRs. Feel free to chime in in [4]
* Review mode
Could you explain this in a bit more detail? Maybe we could open a feature proposal for this functionality.
Hopefully I addressed all your concerns, feel free to add anything or dive into any of the issues, or even contact me personally.
[1] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
[2] - https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...
Overall, I am very grateful that gitlab exists but gitlab.com does make me feel like gitlab over all is a slow piece of software.
The only Enterprise Edition feature that is under discussion is merging without creating a merge commit. We're considering to open source this to make this move work.
GitLab.com still feels slow but running an instance specifically for GNOME should be fast.
I believe it all started when they got a bad rap for doing unspeakable things like supporting minorities to get into the industry, plus one actually wrong decision by a customer service rep approving a complaint about some word in some repository that could be offensive, but clearly wasn't in the context.
Next followed about a month of constant griping about how awful github is, followed by many many features being released which had been in the pipeline all along.
Meanwhile, everybody on HN was trying to find an alternative. Since going back to Sourceforge would have demonstrated slightly-to-obviously that Github was among the best things that ever happened to OSS, the heavy-hitters moved all their projects to Gitlab, which was a third-rate clone of Github at the time, and may or may not have advanced to second-rate since.
Those two projects are, apparently, really enjoying GL.
Everything else requires maintaining more pieces of infrastructure and is not integrated so nicely.
I agree that Gitlab is far from perfect, but it's the best solution in this space IMO.
The ability to view build reports, such as test results and the like.
Tracked many times, in various forms: https://gitlab.com/gitlab-org/gitlab-ce/issues/13227 (73 votes), https://gitlab.com/gitlab-org/gitlab-ce/issues/18664 (67 votes), https://gitlab.com/gitlab-org/gitlab-ce/issues/10982 (53 votes), https://gitlab.com/gitlab-org/gitlab-ce/issues/17081 (22 votes), https://gitlab.com/gitlab-org/gitlab-ce/issues/23618 (a mere 5 votes).
We always run the latest version of GitLab on GitLab.com and we’re working on making (almost) all our deploys downtime free (Issue: [3], MR: [4]). Of course, you can opt to self-host GitLab. It’s easy and quick to setup and requires very little maintenance via our omnibus package [5], and of course, we're here to help you if you get stuck along the way.
[1] - https://gitlab.com/gitlab-org/gitaly
[2] - https://gitlab.com/gitlab-com/infrastructure/issues/?scope=a...
[3] - https://gitlab.com/gitlab-org/gitlab-ce/issues/26130
[4] - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9976
I only have some gripes in the UX/UI:
- On GitHub i find the layout / navigation pretty clear. It's a bit hard to explain this feeling, but the information is always well packaged and that makes it easier to grasp (whether we're talking about commit, issues, reviews and whatnot).
- GitLab has definitely improved (even though it's not that nice that you upgrade and everything moves) but still with their layout (probably using too much % of the screen?) i always am confused. I feel there's "too much information" on the screen and that makes it hard to understand where I am and what I am doing.
But I really really love GitLab Pipelines: we use it pretty much as it was intended (CI using Docker images on a runner, manual tasks for deployments, etc.). And it simplifies a LOT our devops.
https://gitlab.com/gitlab-org/ux-research/issues/7
I would love for you to take a look and give us feedback on the two directions we are considering. When we made a significant change to our navigation by removing the sidebar, most felt that there was "too little" information being shown, so I am intrigued by your "too much" comment.
We've logged countless UX regression issues on their issue tracker and each one has taken 9 - 12 months to fix. Meanwhile, they keep churning out new features that we don't use.
I wish they'd just stop adding new features and spend 6 months fixing their UX and improving stability + performance.
Another data point: I've reported quite a number of issues, all of them have been triaged real quick, and many have been swiftly handled (the last couple were dealt with within a week). The longer ones are mainly larger scope (or depend on one thereof), or - wait for it - adding features.
> I wish they'd just stop adding new features
Every release brings a couple of features that we really enjoy having though, there's a balance to be had. BTW we're self-hosting and performance as well as reliability has been excellent. (disclaimer: happy EE customers).
> You can't add comments on unchanged parts of the code in the diff-view.
Please join the discussion at https://gitlab.com/gitlab-org/gitlab-ce/issues/26722 and https://gitlab.com/gitlab-org/gitlab-ce/issues/14396
> You can't see the what is changed in response to your comment between two MR uploads.
and
> You can't add comments when you view the diff between two uploads of an MR. My list of complaints is endless.
For the following issues I created these gitlab issues to start the conversation. Internally and on the issue there may be a reference to already existing issues covering these subjects.
Thanks for your feedback! You can always join the conversation and/or contribute in order to get things like this shipped faster!
See: https://gitlab.com/gitlab-org/gitlab-ce/issues/32399 and https://gitlab.com/gitlab-org/gitlab-ce/issues/32400
On the left I see the old MR and my comments on that upload and on the right I see the new diff around the commented lines.
I feel that way about Gitlab -- so many people want Gitlab to replace Github, but I can't understand why. "Let's replace product A with product B because Y Combinator." I'm just not sold. If Gitlab were 10x better, then maybe I'd get it, but it's not.
users who don't pay for things.
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10388
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10572
If you have any specific complaints or issues. We'd love to hear about them so we can improve.
This mean they will have full control of the update process, right?
But having to stop working on the thing you're building in order to learn someone else's toolchain, build a fix and (and this is key) persuade another organization that a fix is valuable is incredibly expensive.
They upgrade every week. Who the hell does that to paying customers? And half of their website functionality doesn't work when they upgrade -- but their upgrade-banner always says "no down time is expected". It is a running joke in my company.
We constantly get error 500 during upgrades. Merge requests don't commit. Rebase feature didn't work till a few weeks back. Gitlab runners get stuck every now and then. I use it everyday because of company policy, but folks, Gitlab is a really poor product. Feels like they test their product on paying customers.
Also, do they even know how good their competition is at? You can't see the what is changed in response to your comment between two MR uploads. You can't add comments on unchanged parts of the code in the diff-view. You can't add comments when you view the diff between two uploads of an MR. My list of complaints is endless.