GitLab GitLab Group Kickoffs - Enablement:Distribution, 18 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 16.1 Kickoff - Enablement:Distribution

Description

Planning issue - https://gitlab.com/gitlab-org/distribution/team-tasks/-/issues/1233

A

Hello: everyone, my name, is Dylan Rio I'm, the product manager here at get lab for distribution, and today I'm going to be kicking off our 16.1 release.

A

Here is our scheduling, issue um and I'll go over the general categories that we're hoping to achieve in 16.1, um we're going to work towards security and Appliance improvements, um again, core dependency updates for um for gitlab and improving our contribute experience and our long-term build Vision. So these These are probably familiar. We've talked about these for a couple months.

A

um We recently completed the major release, which was a great step to deliver 160 to our customers and now I'm moving to 16-1. We want to round out a couple of these projects that we were working on before we. We start tackling the major release, um the you know just to go over the general uh reason. Why we're you know hitting these?

A

You know contributor experience and long-term, build efficiency items again, so so heavily um the more that we are able to uh enable both uh any user, but also uh Team teams internally to Implement items into the work that we do in distribution allows everyone to develop uh with more velocity um and basically self-serve. We can work on other things, and teams can feel more enabled without sort of the the lost time of context.

A

Switching um and then that, as it has mainly contribute experience and leading into the long-term, build efficiency, um the more efficient our project is the the less time we have to wait for uh you know, pipelines to run, or uh you know, work to be implemented versus uh CNG and Omnibus. If we can, you know, find efficiencies any way.

A

We can it's just more features uh and more teams that we can enable to roll out features as well um and we're always gonna have to be doing core dependency updates um and then the security compliance improvements are another thing. We're always striving to work towards so um jumping in um not a whole lot of issues. I specifically want to call out um I, just kind of want to show a breakdown based on the uh the ethics that we've got.

A

Many of these are related to contributor experience, but I do want to call it a couple. We have two very important bugs that we're going to be working on in 60. We went one one relates the operator causing it to to loop, as it upgrades minor and major versions, um and so hoping to get this done.

A

um This one's been out there uh for a little too long and really hoping to get across the Finish, Line, This, Milestone and another one related to Italy tokens um that have special characters, um so basically making sure that those are able to work right uh moving down. um So, as I mentioned, increasing the number of distribution, reviewers and maintainers, um so the the less reviews that are on you know a few crucial team members and the more we can expand that knowledge base.

A

uh Not only does it enable folks to um you know, tackle more in different, diverse problems within our team, but it allows like I, said other teams to self-serve and review work, lightning load for everyone, hopefully moving down.

A

um You know this also leads into uh you know, increasing our reviews and maintainers, but just making it easier for um folks to be onboarded so making improvements to our handbook page. uh In this regard, you can see the number of issues and the you know importance we're putting on this maintainer, uh onboarding and Couture experience.

A

We have eight issues related to this experience just in 16.1, um and then uh you know the same thing here for um uh excuse me the the same thing um for uh moving down here to CNG and improving our experience in working with outside teams. Some of these projects are working with external developers and it's uh it's a great use case for us to to learn and grow, um especially you know.

A

Making these multi-architecture Docker builds work uh so moving down here, um there's some Integrity checks, uh kind of related to security compliance, um but you know more um internally uh and then moving down. You know we have secrets management improvements which um I do want to talk about for a moment um and then we'll jump back. So um we we've- we've talked about Secrets management for I would say multiple months. uh You know approaching I'd, say multiple years um and we're making some really good progress here.

A

um So we've recently closed the ability to um uh making it so that these secrets are not stored in plain text on the disk, and so the next element is enabling enabling the configuration to write uh to to not write the plaintext secrets for for the giddly nodes uh that that's the first route. We're going for kind of the the whole Omnibus picture, um and so this is a great first step in in working out towards our secrets, management, Improvement moving forward here, uh just some general maintenance work. We have those essential upgrades.

A

I was mentioning so upgrading nginx to 1.24 um and then updating console to a supported version. um The current version that we're on uh is not not supported any longer, as of February, so um from a long-term support perspective. We need to update now um so we're going to look to updating this to 1.15. If we can, if not, we'll, we'll settle with one uh 1.14 or 1.13.

A

and uh yeah and then running out of efficiency improvements, uh another long-standing project um did a lot of research and time has gone into that we're going to continue making progress on and that's about everything. um Thank you so much for listening um and I hope you have a great rest. Your day.