81–88 of 88 posts
For every release I just go straight to performance improvement https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-re...
The feature releases don’t show up in GitLab’s RSS now... why not? Can’t find any way to subscribe to them. 13.9 didn’t appear and I had to go looking. 13.10 hasn’t either. Blog “news” posts, unfiltered and patch releases all show up in RSS... why aren’t the monthly releases being included anymore?
https://about.gitlab.com/atom.xml currently shows 13.10 as the second entry.
The feature releases don’t show up in GitLab’s RSS now... why not? Can’t find any way to subscribe to them. 13.9 didn’t appear and I had to go looking. 13.10 hasn’t either. Blog “news” posts, unfiltered and patch releases all show up in RSS... why aren’t the monthly releases being included anymore?
Hi, which source are you using? https://about.gitlab.com/atom.xml currently shows 13.10 as the second entry.
I was subscribed to https://www.gitlab.com/atom.xml - at least, that's what Feedly's UI shows, but that URL doesn't seem to resolve at all. In my Feedly, the newest article was "building a better Heroku".
When you search for GitLab in Feedly, you also see that feed, without the 13.10 post. The "GitLab" source at top of search results shows "about.gitlab.com", 6k followers, but no 13.10 post.
I've directly added your atom.xml link so my situation is resolved for now. Thanks!
Earlier quoted context omitted.
One more thought on all of this - we're currently doing some research on problems users face in the merge request. Feel free to take our survey: https://gitlab.fra1.qualtrics.com/jfe/form/SV_9HQQil77CjHJIC... Bonus... you can enter for a chance to win a $75 Amazon gift card.
Docker runner performance is horrible. By using ssh runner which runs exactly the same docker command I save 7 seconds each time. Thid leeds to many hacks to get performance needed (jobs are merged in one big one for example). With many smaller jobs some pipelines run sometimes up to 50% slower than ssh + docker. Also built-in caching is painfully slow. Our self hosted minio instance as custom cache is 10 times faste…
I feel that Gitlab needs to optimize for the 90% use case instead of adding more features. For example does anyone else find Gitlabs diff lacking? It makes reviewing large patches painful, with the seemingly constant fetching of individual file diffs and inability to show large file diffs. The UI in general feels sluggish, especially when compared to something like Gerrit or GitHub.
I'm really noticing the performance on moderate-size code reviews — once you're over a few hundred lines changing their Vue.js code devolves into a JavaScript benchmark doing whatever it does before updating the DOM.
Thanks for that comment. As you can expect, we notice it too. This is something the team is actively monitoring and working to improve (example: https://gitlab.com/gitlab-org/gitlab/-/issues/321691 being worked on in the current milestone).
I am curious: have you tried the file-by-file mode? Some users have given us very positive feedback on this feature, others not so much. It might be something that fits some users' habits but not others. But thought it was worth mentioning. We're actually considering and researching turning this on automatically for MRs over a certain size (https://gitlab.com/gitlab-org/gitlab/-/issues/212849 your thoughts would be very appreciated there, thanks!). https://docs.gitlab.com/ee/user/project/merge_requests/revie...
Not that it solves the root of the problem (that's being addressed too) yet this feature allows for really large MRs to be reviewed without having to render all the changes at once.
Earlier quoted context omitted.
We want to increase both features and usability. It is easier to make something with few features easier to use but we think we can drive both at the same time. For usability we use the System Usability Scale https://about.gitlab.com/handbook/engineering/ux/performance... and increasing it is a target for this quarter "CEO KR: Achieve System Usability (SUS) target of 75. Issue 10314" https://about.gitlab.com/company/…
I’m curious what are some products that successfully do this? I honestly can’t think of any at the top of my head. To me, more features and ease of usability can’t coexist. There must be compromises. I’ve heard the argument that it’s possible by hiding the advanced features, and I would agree in the short term. But internally, as teams grow and have to maintain multiple documentations noting depreciations, it creeps…
Earlier quoted context omitted.
We use buyer based tiering to decide which tier a feature will reside in. https://about.gitlab.com/handbook/ceo/pricing/#buyer-based-t...
> Free is for a single developer, with the purchasing decision led by that same person > Premium is for team (s) usage, with the purchasing decision led by one or more Directors Doesn't this conflict with the stewardship promise that "The open source codebase will have all the features that are essential to running a large 'forge' with public and private repositories"?
Thanks again for the question.
Edit - I've created an MR to document this on our pricing model page: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
The feature releases don’t show up in GitLab’s RSS now... why not? Can’t find any way to subscribe to them. 13.9 didn’t appear and I had to go looking. 13.10 hasn’t either. Blog “news” posts, unfiltered and patch releases all show up in RSS... why aren’t the monthly releases being included anymore?
https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...