GitLab Source Code Group, 17 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Source Code Management FY24 Q1 Category update

Description

What's coming in 15.9, what we are working on in 15.10, where we are headed in the quarter and year.

https://about.gitlab.com/direction/create/source_code_management/source_code_management/#1-year-plan

https://gitlab.com/gitlab-org/create-stage/-/issues/13118

A

Hi, my name is tolston we're heading into a new Milestone 15.10 and we're about to release 15.9 in February gitlab started a new Financial year and also a new quarter. Therefore, I would like to use the opportunity to give you an update for the category direction for source code management.

A

Now before we look into the Future Let's Take, a brief look, what we are going to release in 15.9 so for self-managed users, we're going to release gitlab sshd, which is a standalone SSH server which compared to open SSH, will give you metrics connection. It will give you more logging than openssh more login detail, and it will give you graceful shutdowns for your SSH connections when you're operating behind a proxy. It will also pass you on the original IP address.

A

Gitlab has been using it since 15.2 in github.com and 100 of the traffic has been going through. Since then, it started as a community contribution, gitlab sshd and therefore I want to give great thanks to Lawrence Boone who started this. Thank you. Luance.

A

Another contribution is um from jiho, um which is an important Improvement around Kono code owners. So far, it's only possible to require um an approval of a code owner or make it optional, but it would only be one approval required with this change. You can now require multiple approvals for certain parts of your code base files directories, file types like code owners in general, but now you can say I want multiple approvals for certain users, certain parts of the code.

A

So far, if you wanted multiple approvals, you had to revert to approval rules which are for branch and not for specific directories or files. Therefore, if you require multiple approvals, it would be for the whole Branch. Even if minor things were changed, it would still have to have two approvals for your merge request, so it resulted in more uh approval work than with this solution now, so, where we're heading in this year, um I want to talk about four things. Today: Branch rules, working tags and code owners, um I start with Branch rules.

A

We've been working on Branch rules for quite a while. What is it about? um Traditionally, our settings are in different places. We have settings for protective branches under repository. We have settings for approval rules and Status checks under merge requests in the settings, and it was hard for users to put these different things together in their mind and clearly understand which rules apply for which branch and it seemed to us that our users want to think about the rules in connection with branches.

A

Therefore, we're changing the setup and creating a new thing, which is Branch rules. Well, you will find all the rules that apply for a specific Branch or a specific Branch wildcard or for all branches. So you will find here in the settings a summary of the rules that apply and then you can also see the details for the branch protections or the approvals and also for the status checks here in the first iteration of this.

A

You will still make the changes in the traditional places, so you will manage Branch protections under repository Branch protections and manage merge, requests and also status checks under uh in the section settings mode requests.

A

So that's going to be released in 15.10, then we've also done user tests and generally the create stage performed very, very well.

A

One thing is why we didn't perform very well: was the operation of protecting a branch users uh always thought when they want to protect the branch they would need to go to repository branches and then somehow find the setting for protecting the branch here now in the past, because our settings were in different places, it wasn't possible for us to give a good, deep link here for changing those settings now that we have them all in one place. What we will do is provide links here on this page to change the settings for specific branches.

A

This will improve the end-to-end experience around protecting branches and setting different rules for branches.

A

We are going to start with this also in 15.10, and we're going to continue this in the quarter, where we will add more crosslinks between code owner file and and settings for requiring code owner approval and the other way around and and so on. We're also going to um and later in the year we're going to further work on Branch rules where we will allow you to edit Branch rules right now.

A

You can only um you can only view those branch rules, but in the future we want you to also edit them right here in the detail view right so much about Branch rules. The next topic is forking.

A

um Let me go right uh to how this will look like we're going to add a new UI element here. That shows you in your fork how far it is ahead of the parent project.

A

How many commits it's ahead and how many commits it's behind, and if it's behind the parent, we will show you a sync button that will allow you to sync it with a click of a button and if you're head, then you will see this create, merge request, which will let you create a merge request on the parent project, so contribution becomes easier um until now, you would have to do this on the command line, and we think this will be a huge Improvement for the forking workflow.

A

The next topic is attacks. We want to um improve the experience with the tags, to make it more transparent, which commits have been tagged. Tags are very important feature in git and we want to surface it more so in the future. In the tag in the commit list, you will see the issue um the commits that have been tagged. Let's briefly, look at how this looks now right now. You will see the list of commits here, but you will not see any tags here.

A

So if you want to see tags, you have to go here a way. You can also see the commit ideas here which have been tagged and you would have to go back and forth forced to understand this. This is a very um requested feature, so we're going to release this, probably um in 15.

A

15.10 and then maybe later this quarter we're going to also improve the commit detail page where we will show you um and which branches commit is present or which branch has it as a tip. Likewise, with the tags, some of these functionality is already there today. However, if you have a large project with many tags or many branches uh will not be able to display it now, and we hope we can make improvements that, even in those cases where you have many tags and little branches will be able to show you, this information.

A

So much about tax uh finally code owners, I've already mentioned the contribution of um jihu um we're going to do more work in that direction, that addresses large organizations or that addresses organizations with mono repos. One thing that we're planning to do- hopefully this quarter or a bit later than this quarter, is multiple code owner files, which will allow organizations with mono repos to um to have multiple Corona files that are manageable by different parts of the organization.

A

So there is a separation of ownership of the code owner file, so they can control that individually and yeah.

A

So much about that um parts are very popular, especially from users that have mono repos.

A

Then we also want to improve the experience of creating a code on a file and also maintaining a code on a file. We've observed that um it's hard to understand uh the syntax, it's hard to understand how to maintain these files. So we want to do a couple of improvements here. We will start, uh maybe in this quarter um with syntax, highlighting and basic validation of the coronophile, so basic validation means syntax validation and then later this year, we'll do more advanced things um we want to.

A

um We want to do a validation to understand whether the users that are ended up are still existent. We want to validate whether the files are still there, so this is more for something later in the year and um so much about these plans since we're starting a new quarter. I want to also outline what we're doing with the okrs in this quarter and the coming quarters.

A

So I've talked about this overall score that wasn't very good here. It was poor, so we hope with these improvements about the overview and about these end-to-end experience for branch protections, we will reach a um at least Fair score in the next uh review of this user benchmark, and certainly this is not our end goal.

A

um We will add also editing of Branch rules, and we hope, then, that we get a good or excellent score, um but that's for a later quarter uh to have as an okr uh code owners we're also going to prepare a longer sequence of uh key results that we um are laying out here. So in the beginning, we want to do the engineering work in q1 and Q2 to help users understand the code on a file, better syntax, highlighting and syntax validation.

A

Later we want to do um more advanced validation and we want to start tracking how many code owner files are broken, and we hope that those improvements we will have less code on files broken over time um and basically in q1 and 2 we're going to do the engineering work and in Q2 and Q3 we're going to track this and see how the engineer will actually improved the um experience by having less broken code.

A

Ronophiles and by also seeing that more organizations dare to pick up a code owner creation, we'll have um more objectives and key results around resolving customer bugs and also maintenance work by removing feature. Flags.

A

So that's it. um If you have questions, please consult this page, please reach out to me: it'll be shy. My name is here and the very last thing that I have to say disclaimer all the things that I said are what our intentions are today, but these intentions can change as the world changes. So please don't make any purchasing decisions or planning decisions on Facebook. uh The information that I gave here um I hope you, like this update, have a good day. Bye.