GitLab GitLab Group Kickoffs - Create:Source Code, 17 Mar 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 12.10 Kickoff - Create:Source Code

Description

See what else is in store for the Source Code group in 12.10 in our planning issue: https://gitlab.com/gitlab-org/create-stage/issues/12620

A

Hi I'm James Ramsay group product manager here at get lad, and this is the source code group 1210 kickoff call I've got quite a few items, I'd like to share with you that we're planning to work on over the next release and some really wonderful improvements to merge, requests and yeah. Without further ado. Let me jump in so. The first item is to do with the gifts that are displayed in merge requests.

A

I think I've covered this in previous kickoff calls, but essentially there is a situation where the merge request, if can display misleading information if you've merged the master branch back into your feature branch and then intend to merge it.

A

Your feature branch into master at a later date, you'll end up with a confusing set of changes and due to the way it calculates the diff, so we're working on an improvement called merge rifts and we've built a bunch of changes around this and we're working on commenting on this new form of diff and also on completing some back end work.

A

In order to enable this feature- and there were some structural changes required to calculate this new diff- and so we're still working out the finer details of that that exact term that part the asynchronous merge ability check- is the specific area that's blocking, enabling the earlier proof of concepts that we've built.

A

So this is a really exciting improvement working hard to make this available in some form as soon as possible, and we hope to start testing this on Gilad com over the coming weeks, as well with comments disabled, but we'll be adding comments which are important for more broader adoption of this feature without the ability to comment on add if the value of it is greatly diminished.

A

So we're really keen to get commenting turned on so that we can really get this new diff mode in front of customers and they can tell us what they think the next improvements relate to code intelligence. So, two releases ago we worked on added building a proof-of-concept of native code intelligence inside of get lab, and let me show you what it looks like you can see this on gate lab comm.

A

For a couple of commits here and there, where we have started testing it and when it's available you just open the repository browser and it'll start showing code intelligence data, and this is really really useful. You can jump to definition and it'll pop you over to the correct line and they're still early days. That probably should have just reloaded now jump to a different section on the file without loading the page. So you can see this is still early days.

A

But what we're really keen to do is get this code intelligence into the birds request, because really, when you're reviewing code, that someone else is written having code intelligence is really valuable. Because then you can quickly understand how everything's linked together and when you're reviewing someone else's code. You won't necessarily have the same familiarity with the work they've done and how it'll looks together. So we think it's actually much more valuable to have this feature in the merge request interface than in the repository browser.

A

But the repository browser was an easier place to start with the POC, so we're continuing to expand the work we've done here, but this still is I guess a proof concept, even though we're expanding the interface support more broadly to get lab. There are some challenges with making this work by default for every project, on your lab on Gilad, calm and self hosted, and that's one of the things that we're continuing to look at, which is working out our data storage model.

A

So we've been doing some investigation in 12.9 and we'll be continuing to that into 1210.

A

Eagles been doing some great work digging into this, but essentially the progress we've made so far is to work out that we could end up with a table in Postgres database. That's 10, terabytes, full of code intelligence and so we're not sure if that's the best idea or if there's other ways of storing this data and presenting it to users that won't be such a headache for database maintenance and our self hosted customers that might end up with massive databases. So that's really the major hurdle. That's preventing us from sharing this.

A

More broadly and making this feature work for everyone, and how can we store this much data and make it queryable and just showing the interface? So that's exciting progress on code intelligence and we look forward to a release sometime very soon, where we'll be able to enable that by default for everyone, the other feature which I am excited about I know. Lots of other people are excited about. There's a multi-line comments, but this is the first minimal viable change to start building multi-line comments.

A

So we've been thinking about this for a while doing a bunch of UX research into how the interface might work. What kind of behaviour people expect?

A

How can we consider accessibility depending on Mouse, drag operations versus keyboard and how we can make it work well for everyone, but in the meantime, we want to start building the first minimal iteration that we can learn from and the first version that we think we can ship and in 12.10 is a very basic version where you click on a line, and then you expand the range upwards by typing. An integer in the Box.

A

Saying like this is the line I'm commenting on and the ten lines previous or the three lines previous we'll get to build the back end and solve a bunch of problems there and we'll get to start building the front end have a working version where you can leave a multi-line comment if you really really want to, and but importantly, you can still start, we can start solving all the challenges like what happens about multi-line comments that go over change and unchanged lines, because in get there, you can comment on any line in a file.

A

What happens if someone tries to comment over a really long range, one of the behaviors that we need to consider there so we'll be working a bunch of those challenges without building a really great looking drag-and-drop interface?

A

That I guess is what most people are expecting and hoping for, and that's what we intend to build in the future, though we're starting with this minimum iteration, where we'll get the the basics of multi-line comments built and we hope to follow up in 13.0, with some significant improvements to the interface but we're just taking it step by step and we'll listen to feedback and yeah we're committed to bring this feature out in a version of get lab coming very soon.

A

So these I guess there's a three major areas that we're improving on the source code group in the top top 10 release.

A

I think they're going to be really beneficial, multi-line comments so exciting, but also code, intelligence, I'm, really looking forward to that and I'm hoping that we can solve a lot of the hard problems about how we make it work for everyone by default, so that everyone has code intelligence that just works and murder of Deus is going to be a a great improvement for customers that practice merging workflows that result in sometimes confusing gifts.

A

So that's it from source code and we'll see you next month on me: 13.0 kickoff, exciting release coming up for that too. Bye.