[HN Gopher] Gitlab 13.10 Released
___________________________________________________________________
Gitlab 13.10 Released
Author : bjoko
Score : 104 points
Date : 2021-03-22 14:41 UTC (8 hours ago)
(HTM) web link (about.gitlab.com)
(TXT) w3m dump (about.gitlab.com)
| lrm242 wrote:
| Can we just get a decent unified Notification Center, please?
| Notifications in GitLab are painful, just copy how GitHub does it
| and stop trying to make it so complicated.
| masklinn wrote:
| Not being a gitlab user I'm surprised its notification are
| worse than github's, because it's not like github's
| notifications are any good. Between the comment notifications
| which don't link you anywhere half the time (possibly on inline
| comments? I never remember) and the update notifications which
| give you a completely empty diff on a push force, it only
| serves to signal that something happened on this thing you
| don't even care about.
| lrm242 wrote:
| All GitLab notifications are via email unless someone
| explicitly @s you. Furthermore, there is no api to
| notification. Basically, unless you monitor email, you don't
| get notifications. It's horrible.
| spockz wrote:
| Instead of watching general notifications I just subscribed
| to specific RSS feeds for issues, mr, etc and use RSS as my
| notification engine.
| masklinn wrote:
| Wow that does sound nasty indeed.
| sytse wrote:
| We try to make a little bit of progress on many features each
| month. So most of the time we won't have any giant new features,
| progress happens iteratively. You might also notice lots of
| deprecations as we get closer to 14.0 (immediately after 13.11)
| Happy to answer any questions.
| Operyl wrote:
| Why isn't the what's new section in Gitlab updated for 13.10?
| It still says "13.9 (Your Version)".
|
| EDIT: That is, the one under the help tab in a Gitlab instance
| on the top right.
| sytse wrote:
| On https://gitlab.com/help I see 13.11.0-pre as the version.
|
| Maybe you're working on a self-managed version that still
| needs to be updated?
| Operyl wrote:
| I'm talking about this: https://i.imgur.com/isbEqn6.png
|
| My instance is definitely updated, I did it myself and
| verified the version number in the Admin section.
| kennyGitLab wrote:
| Hi Operyl - GitLab Product Leader here. Our process for
| updating the What's New content is delayed slightly from
| the release (as we use the release post images that are
| published on the 22nd for the What's New highlights).
| They'll show up shortly.
|
| https://about.gitlab.com/handbook/marketing/blog/release-
| pos...
| kennyGitLab wrote:
| Here is the MR for 13.10 What's New Content. You'll need
| to update to the first point release after 13.10.0 to get
| this content. https://gitlab.com/gitlab-
| org/gitlab/-/merge_requests/57119
| Operyl wrote:
| This seems really bizarre to not be included with the .0
| release. The features are live, but the label states
| "Your instance (current version) is 13.9". It could do
| with some more refining perhaps.
| mkarampalas wrote:
| Hi Operyl, GitLab PM here. Thanks for the feedback on
| What's New. As you point out, it looks like we have some
| opportunity for refinement and better/clearer messaging
| for folks that update right away to the .0 release. I've
| opened up this issue to track that work and welcome your
| feedback or ideas there. Thank you!
| https://gitlab.com/gitlab-org/gitlab/-/issues/325591
| kuizu wrote:
| The Gitlab licensing model was recently change and the lowest
| tier starter license was removed. Anyone knows which of these new
| features a customer receives that is still on "starter" (which
| can be kept for up to one year after the change to the license
| model)?
| john_cogs wrote:
| All new features target Free/Premium/Ultimate. Starter customer
| are still getting new features, improvements and fixes -- they
| are the same features that are also available on the Free tier.
| For Starter customers who elected to upgrade to Premium for
| free, they will also have access to the new Premium features.
| thiagocsf wrote:
| You stay on basic until your subscription expires or you
| upgrade: https://about.gitlab.com/pricing/faq-new-product-
| subscriptio...
| ksec wrote:
| For every release I just go straight to performance improvement
|
| https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-re...
| ktpsns wrote:
| I like Gitlab's OSS philosophy and documentation (including these
| lengthy release notes) a lot.
|
| If there's one feature I really miss in Gitlab than the limited
| issue trackers. Despite Jira is still the "go-to" solution in
| many companies, I feel that many try to avoid that monster of a
| software, especially since Atlassian no more offers a self-hosted
| variant. I'd love to see more things like GANTT charts included
| (there is only a Kanban board display for issues, not yet some
| Waterfall or agile/GANTT board).
| emerongi wrote:
| An issue for us is that we need to provide outside users access
| to support tickets. Gitlab has Service Desk, but it's useful
| only if it's just your engineering team looking at the issues.
| Service Desk issues often need attention from someone outside
| the engineering team, though.
|
| There's a steep step-up from Premium (which we are at) to
| Ultimate to get guest accounts, but even with guest accounts,
| we'd need to separate access of service desk tickets from
| internal tickets.
| ktpsns wrote:
| Jep, I've also noticed many shortcomings from the gitlab
| service desk feature. For us the problem was that when
| replying users by email, they could not open attached files
| without an account on our installation.
|
| Redmine has these features since a long time, and I think
| it's worth for Github to catch up...
| tyingq wrote:
| It does feel like Gitlab strategically keeps certain things out
| of the OSS product, like limiting the issues to two states.
| john_cogs wrote:
| We use buyer based tiering to decide which tier a feature
| will reside in.
|
| https://about.gitlab.com/handbook/ceo/pricing/#buyer-
| based-t...
| adduc wrote:
| > 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"?
| john_cogs wrote:
| Have you seen the Roadmap feature? It may be applicable to your
| use case.
|
| https://docs.gitlab.com/ee/user/group/roadmap/
| stevenhuang wrote:
| 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.
| majkinetor wrote:
| Really looking forward for VSCode full blown merge reviewing.
|
| Impatiently wafting for this so I don't have to use sluggish
| browser any more:
|
| https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issu...
| phikai wrote:
| I'm so excited for this too! I'm really excited to continue
| bringing GitLab workflows closer to where developers are
| doing their work and hope this is going to be a really
| meaningful step in that direction.
|
| I'm also interested to see what kind of impact it has on
| large MRs, but do know it's not the answer for what happens
| in GitLab.
| phikai wrote:
| Hi! Thanks for the feedback on diffs - it's something we're
| always thinking about and working on in the group.
|
| One of the things we're currently working on is putting
| monitoring in pace for all the of the diff limits -
| https://gitlab.com/gitlab-org/gitlab/-/issues/31063. The goal
| here is that we can further fine tune some of the limits in
| place to continue to help with larger merge requests.
|
| The group also spent some time investigating ways to improve
| the blocking time for large merge requests and you can see some
| of the discussion around that here: https://gitlab.com/gitlab-
| org/gitlab/-/issues/295237.
|
| The last issue I'll drop here is https://gitlab.com/gitlab-
| org/gitlab/-/issues/241841.
|
| You can also see all of the other issues related to performance
| that the Code Review group has been working on in GitLab here:
| https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8...
|
| Thanks again for the feedback - and know that this is something
| we are looking in to.
| phikai wrote:
| 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.
| apple4ever wrote:
| REBASE IS HORRIBLE! That's a good first step to fix.
|
| (And yes I filled out the survey).
| apple4ever wrote:
| Agreed. Diffs and MRs in general are terrible. We get 500
| errors constantly when submitting MRs, if we can push up at
| all. And don't try to rebase with the button - OH MY it will
| just fail. Or it will succeed and the interface will not
| update. Yuck.
|
| We are switching to GitHub. Which saddens me because I much
| prefer GitLab's interface. But I have lost the battle, due to
| GitLab's terrible performance.
| acdha wrote:
| 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.
| ulrikrasmussen wrote:
| So much second this. It actually feels like it is getting
| _slower_ on each upgrade, and more buggy. Am I the only one who
| finds that the "go to next unresolved" button now often goes
| into an inconsistent non-working state that requires a (slow)
| refresh? Given that I spend most of my time on GitLab
| reviewing, this is a real pain point for me.
| phikai wrote:
| > Am I the only one who finds that the "go to next
| unresolved" button now often goes into an inconsistent non-
| working state that requires a (slow) refresh?
|
| I don't think I've seen that reported before and we have been
| working through some interesting to reproduce issues in
| recent milestones.
|
| Would you mind opening an issue for this? Feel free to tag me
| (same name).
| diegocg wrote:
| The thing I miss the most from the reviewing process is the
| ability to review diffs per-commit.
|
| This is closer to how git is used in the linux mailing lists
| but gitlab completely breaks that workflow. Github has added
| some support for that. And yeah, performance sucks, even for
| trivial patches.
| phikai wrote:
| Hi! I'm not sure if you've seen this, but in GitLab 13.0 we
| released commit based navigation for merge requests. You can
| read more about this in our docs, but we'd love any feedback
| you have on the feature.
|
| Documentation: https://docs.gitlab.com/ee/user/project/merge_
| requests/revie...
| john_cogs wrote:
| When using merge requests, each push to a branch creates a
| new version. You can then compare between any two versions
| and review the diff.
|
| Documentation: https://docs.gitlab.com/ee/user/project/merge_
| requests/versi...
| diegocg wrote:
| Not very helpful unless you push every commit individually
| sm4rk0 wrote:
| This one should've landed, too:
|
| "New predefined variables for job start time and pipeline created
| time"
|
| https://gitlab.com/gitlab-org/gitlab/-/issues/22901
| ZeroCool2u wrote:
| I really like how GitLab is shaping up. I hope they start getting
| a bit more mind share from GitHub, but I think they really shot
| themselves in the foot with that recent pricing change. [1]
|
| Having to pay the same amount per license, for folks that just
| want to create/edit or even just view issues, as a full blown
| developer is simply not tractable. There's a lot of value in the
| platform and all else equal I'd probably pick GitLab if I had to
| choose between GitLab, GitHub, BitBucket, JetBrains Space, or
| _Shudder_ Azure DevOps.
|
| But the price. Damn, it's just impossible to make that argument
| to yourself, never mind your CTO.
|
| 1: https://news.ycombinator.com/item?id=25918717
| TheChaplain wrote:
| You can voice your input here on the matter of non-developer
| accounts;
|
| https://gitlab.com/gitlab-org/gitlab/-/issues/213185
|
| The more feedback they get the better.
| apple4ever wrote:
| Its been years like that. They aren't going to change.
| merb wrote:
| yeah, my company aswell, we only need 1 required reviewer, but
| paying for that like $19 per user (we are 5, so $95 for that
| per month) is a little bit ridiculous. granted it probably
| comes with support, but as a small company you do not care
| about support, you care about $1200 a year. I loved the
| jira/stash pricing, 10 person shop was $10 a year so $30 with
| stash + jira agile (there was a time where agile costed extra),
| but no support. the price of course was ridiculously cheap, but
| granted that was something were you did not even needed to talk
| about the cost, it was assumed that it was worth it and there
| was no cost/feature evalulation.
|
| edit: kudos to them they already offer tons of stuff for free.
| ilmiont wrote:
| 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?
| [deleted]
| crubier wrote:
| From my perspective, Gitlab needs to urgently reallocate 90% of
| its developper force from "Adding new features in 10 different
| axes" to "Stop adding new features and exclusively work on
| performance and consistent unified UX".
|
| I know it hurts, I know it's probably not what devs at Gitlab
| aspire to, but I believe it is much needed. Possibly, an entire
| rewrite of some core aspects are needed. I have a lot of trouble
| selling Gitlab to my team. Everyone just wants to move to Github
| to have a simple UX that works.
| sofixa wrote:
| Their best shot at competing with GitHub is on features ( and
| they do a pretty good job at it too), so i think they can't
| afford to stop shipping new features.
|
| GitHub's UX is simple because it doesn't even come close to
| what GitLab provides, even in the free tier, and their
| iteration is much slower. If GitHub had GitLab's features it'd
| have a complex in some places UX as well.
| nickjj wrote:
| If anyone from Gitlab happens to read this, how is ActionCable
| working out for you on gitlab.com? If you're not from Gitlab but
| use ActionCable at moderate scale feel free to share your story
| too!
|
| I casually read a few PRs and issues from a year ago where you
| discussed introducing ActionCable but it looks like a full blown
| report hasn't been written up on how it panned out, but I do see
| it being referenced in your HTML.
|
| Concerns were mainly around memory usage, such as it growing to
| pretty huge sizes even with idle connections. I know there were
| lots of horror stories of major memory usage early on. The memory
| growth climbed very quickly with active connections, but I wonder
| now with Rails 6.1+ if those issues have been ironed out.
| sytse wrote:
| Last thing I heard we're no longer worried about memory usage.
| We where thinking about using AnyCable to address memory
| concerns but that is off the table at the moment because it
| isn't an issue anymore.
| nickjj wrote:
| Thanks.
|
| Are you no longer concerned because memory usage dropped
| significantly?
|
| How's the overall latency?
|
| I remember seeing some benchmarks where ActionCable was using
| like 1-2gb of memory for around a thousand active connections
| with 95% percentile latency in the multi-second range to
| broadcast a message. I do see AnyCable makes huge
| improvements here and I love the idea of it but also not too
| sure how backwards compatible it is with Hotwire / Turbo
| Streams.
|
| I've always thought Rails was good / fast enough but the
| ActionCable stuff worries me a little because a single low
| end VPS could happily handle a very solid amount of traffic
| (tens of thousands of daily page views, etc.) but once you
| start factoring in websocket connections that changes
| everything. Suddenly pages that have completed the request /
| response cycle are still on the hook to keep a ws connection
| open even if they're not doing anything that causes a state
| change.
| systemvoltage wrote:
| I am curious, at what point will the features stop? Do we keep
| adding features until Gitlab becomes impossibly complex to use or
| onboard anyone? Why isn't Gitlab built like a modular app - add
| what you want but core should be simple as possible and feature
| complete. I am afraid but this is how a lot of applications die.
| Gitlab is starting to get bulky and obese already.
| Operyl wrote:
| I feel like it's already .. kind of there. There are so many
| features that I'm lost in them, and some of them feel like
| they've been abandoned already.
| alfg wrote:
| It's definitely becoming more bloated and slow with every
| release. I hope to see them focus more on optimizing
| performance soon.
| jayd16 wrote:
| IMO features are fine and its more about the cognitive load put
| into the happy path, which still seems low.
| zertrin wrote:
| Yeah, I was an avid user of self hosted gitlab previously, but
| the pace of added bloat^Wfeatures was just too much and I
| ditched it for gitea about 1 year ago.
|
| I feel gitlab's is now mainly aiming at large enough companies
| which actually use all of these features.
| enraged_camel wrote:
| Not sure why you feel that added features result in "bloat".
| We've been on Gitlab for 4 years now, and our core workflow
| not only hasn't changed, but also has not been impacted by
| any of the new features. On the other hand, we've expanded
| our usage beyond it, and it's always nice to need a feature
| and find out that it is right there under a menu and just
| needs some configuration to get it to work.
| tyldum wrote:
| With them dropping the lowest license tier, you better
| start using all the features... We have been Enterprise
| users since 2015, but are evaluating our options.
| wernerb wrote:
| Just take a look at the gitlab ci reference. It is huge. And
| there are competing features in there that are intended to
| "deprecate" the older feature but this doesn't happen. They are
| also constantly held back on providing backwards support. For
| instance, adding dpeendency-like flow as opposed to stage based
| flow has been added but it's not possible to model dependencies
| from same stage making the whole thing kind of useless.
|
| Versioning the yaml specs/apis is the correct move. I hope
| future CI systems take note.
| jayd16 wrote:
| Seems trivial to add a version field to the root object if
| they ever go down that route.
|
| I haven't had any older yamls break and I wouldn't say the
| yaml schema is worse off because of backwards compatibility.
| Not sure a version would change much atm.
| theptip wrote:
| I think this is a real strategic challenge for Gitlab; I think
| the answer is "the features never stop", and that is OK, as
| long as you understand their target customer/market.
|
| I first started thinking hard about this when they recently
| cancelled their bronze tier subscription. Gitlab is clearly
| ducking out of a brawl with Github for the individual/consumer
| $5/month tier; that makes sense as there is no way Gitlab can
| win by taking on the incumbent on their own turf. Instead
| Gitlab seems to be shifting focus to targeting larger
| enterprise customers; those who are fine paying $20/mo or
| ideally $100/mo for a one-stop solution to the full SDLC. (The
| counterargument here would be that they _are_ still targeting
| the $5/mo customer, they are just trying to replace a $5/mo
| Github subscription plus a $10/mo CircleCI sub plus a $10/mo
| Jira sub etc. -- I'm not sure I see that end of the userbase
| being as amenable to bundling though).
|
| The largest enterprise customers will keep asking for more
| boxes to be ticked, because it's usually easier to add features
| onto your existing solution than to stitch multiple solutions
| together, and because the more features/config options you
| have, the more complex configurations/requirements you can
| satisfy. However that means you get feature bloat, and pricing
| becomes more challenging; you need to charge more for "all the
| features" tier, but as you broaden the offering, fewer
| customers actually want to pay for everything. "What do we keep
| in the $100/mo tier?" is a challenging question to get right as
| the feature-set grows.
|
| As you get into enterprise sales, you start to need more
| customization/unbundling. Before I moved back to Github I paid
| Gitlab $20/mo per engineer on my team and would never dream of
| jumping up to $100/mo, but would absolutely have paid more for
| a la carte access to certain features from the $100/mo ultimate
| tier. (For example I have no interest in their issue tracker,
| but I'd love to have been able to use their DevOps / Kubernetes
| tooling).
|
| I believe this sort of a la carte pricing is less developer-
| friendly because you tend to need to talk to a sales person vs.
| just having the developer sign up, but then I don't believe
| that "developer first" is your sales strategy in enterprise;
| see Okta vs. Auth0 for a good example:
|
| https://auth0.com/pricing/
| https://www.okta.com/pricing/#customer-identity-products
|
| Auth0 keeps it as simple as possible. Even within customer-
| identity (their competitor to Auth0) Okta has way more
| configuration for add-ons like MFA, SSO etc.
|
| (I know @sytse / Gitlab folks post on here regularly so I'd
| love to hear their feedback on whether I'm completely off-base
| in how I'm thinking about this stuff!)
| sytse wrote:
| Thanks for inviting me to comment. I think we still cater to
| individual contributors with our Free offering.
|
| It isn't so much about the customer but about the product.
| Our ambition went from being a source code tool to a complete
| DevOps platform delivered as a single application.
|
| I think a lot of the changes you see can be explained from
| that.
| sytse wrote:
| 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/okrs/fy22-q1/
|
| Regarding user interface modularity you can already turn on and
| off many parts in the front end https://imgur.com/a/aIRkDmt
| selykg wrote:
| > but we think we can drive both at the same time
|
| Eh.. I think the comments here are telling otherwise. I'll
| admit I haven't used Gitlab in over a year now. But I know
| the entire team I worked with really despised the switch to
| Gitlab internally. So much so we dragged our feet as the only
| team staying on Github while the rest of the company moved to
| Gitlab as long as we could.
|
| It was a really unpleasant experience using Gitlab. The
| diffing in particular was truly awful by comparison. And in
| general everything was slower with Gitlab.
|
| You should rethink this mindset of doing both at the same
| time and focus more on making what you have now better. It
| would likely benefit you greatly.
| jehlakj wrote:
| 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 on the user's end. It becomes harder to read
| documentation and there's also the burden of trying to
| understand what it's for because it was something that
| replaced a previous feature which I don't have context for.
|
| Please add features responsibly, and stop rewarding new
| features that seem helpful in a handful of use cases. But who
| am I kidding here
| sytse wrote:
| I'm inspired by products like Zoom, Chrome, VScode, and
| Slack that are both user friendly and full featured.
|
| Any examples of features that we probably shouldn't have
| added and should consider removing?
|
| We intent to replace the DIY DevOps toolchain with GitLab.
| Something that consists of many applications and
| interfaces. Just having it in a single application would
| already be a big quality of life improvement for the users.
| And so far the most common hurdle is being able to match
| the functionality of the point solutions.
| jimmyed wrote:
| The worst manifestation of these force fit features are the
| Kubernetes ones. That integration is wonky to say the least.
| LeSaucy wrote:
| The idea behind it is sound. Its a massive timesaver to be
| able to live-review apps as part of merge-reviews.
___________________________________________________________________
(page generated 2021-03-22 23:04 UTC)