 Hi everyone, it's 4pm here in Edinburgh. I'm in the middle of a heatwave so it's 23 degrees outside at the moment. Apologise if I melt during this call. I'm going to share my screen. So it's time for the update on what the discussion team has been doing for the last five weeks. 9.3 is going to be released later this week. Some of the features that we've been working on in there, the conversational development index. This is a feature available to GitLab instance administrators. So gitlab.com users won't really see much of this but people who run their own GitLab instances will see it. And it's a way of showing people how their usage of GitLab compares to other uses of GitLab. So if you have the usage being enabled, you send data to us and we provide this back. Not in exchange but we provide this back. So it shows you, for instance, if you're using GitLab CI, more or less than other related people. And Adam's been working on that. It looks really nice. So the developers continue to add nice stuff to snippets. So now snippets can have descriptions as well as code, which is awesome. That's in addition to having comments as of 9.2. As well there's been working on something that's user facing but not like noticeable to users in the sense that they won't see anything in the UI. It's a feature that lets us restrict certain features to name spaces on gitlab.com, which means that we can let people buy into e-features on gitlab.com. And Jak has been working as well on improving the JIRA integration settings. So if you have your JIRA host split by web and API, maybe different ports, maybe different host names, you can configure that again. Valerie's also worked on a really cool elastic search improvement, which is that now if you search for part of a camel case name, it will show you that in the code search. Previously it would only show you if it was prefix. So in the example there, I don't know if you can see the screenshot very well. But he searched for files and archive, from expected files and archive. Previously it would work if you searched for expected files, but it wouldn't work for files and archives. So that's really nice for people using camel case languages where camel case variable names are common. And this is a community contribution that Adam helped review along with Annabelle in the blame view, which we now call the annotate view, but hopefully you know what I mean. We have a little key that shows how old a line is. So you can see in the screenshot that the oldest lines are sort of have the fainter color in that sidebar, and the newest lines have the darker color. So that's a really cool feature. I was going to have some stuff about performance improvements here, but we are still the measurements. We only deployed most of the 9.3 features today. And I've noticed for one of them we still need to add an index to make that improvement work the way it should. And for other ones we're seeing, you know, the database has been hammered pretty hard today. So I'll try and get some charts added to this presentation later on. Things that didn't go so well in 9.3 or in general, relations between issues slipped again. It slipped from 9.2, which wasn't a huge problem. That it slipped from 9.3 is not so great. I don't really want to go into too much detail here because there is a huge amount of text. First of all, there's a retrospective for related issues itself. And second of all, there's a bunch of stuff about related issues in the general retrospective document we have from 9.3. So I'll let people read those and have their comments there if they want to. We also need to make merging merge requests more reliable. Basically if, for whatever reason, we can't update the lock status. When you try and merge a merge request, it goes into a locked status. If we can't update that, when we attempt to merge it, after attempting to merge it, so that it's unlocked, we make people wait 24 hours, which is a really long time, and it's a really bad experience. It's just really, really annoying. So I hope to get to that in 9.5. And we still haven't done the public API for merge request diff discussions. That's partly because we're working on adding those discussions, resolvable discussions to issues as well. So we'll do it all at once, but it's kind of annoying to me because it's obviously the biggest gap in our current REST API. In 9.4, and beyond that, we've got a bunch of exciting stuff. So we've got native group milestones. At the moment we have a thing called group milestones, but all we do is group milestones within the group, projects within the group that have the same title. But this is real group milestones congruent to group issues and, sorry, group labels. And once we do that, group issue boards will be able to use those group milestones and group labels, and we'll be able to build group issue boards. Janine has also been working on a declarative policy framework, which is a new DSL, the main specific language for our developers to use when they're assessing permissions or policies. It makes it easier to extend for E, and it also makes it easier to do things. So we normally have a couple of different permission checks we do. We say, for instance, can this user do this action on this thing? Or we might say, which users can do this action on this thing? Or we might say, what actions can they use to do on this thing? So we've duplicated logic in some places to make some of those faster, but this framework makes it easier to just declare that you want that and let the runner, the framework, the policy runner, handle that for you so that you don't have to duplicate the logic in a couple of places, which hopefully means fewer bugs and we keep the same good performance. Valerie is working on a Slack app for GitLab.com. The reason it's restricted to GitLab.com at the moment is that as it stands, Slack apps can't be configured easily to set a different endpoint. So when you authenticate with a Slack app, you have to authenticate with a known endpoint, which in this case will be GitLab.com. But we're hopeful that that'll be possible in future. So the work that's being done on this might be available to people using self-hosted GitLab in future or just non-gitlab.com. Also, might not make it into my.fi, but I mentioned this last time, integrating into the Jira development panel, there's a community proxy, which is written in Java that allows this at the moment, and we will probably take the same approach initially, which is Mimic GitHub Enterprises API and OAuthflow. And if people configure GitHub Enterprise with the instructions we give them in Jira, they will get their GitLab instance, which will let them see commits, merge requests, pipelines, and so on in Jira, which is really awesome. As an ex-Jira user, I would have loved that. One of the slowest things about loading a merge request is if we have a merge request that has a lot of commits initially, and then we add commits to it. So say we have a merge request that initially contains 200 commits, and we add 70 commits to that one by one. We get the pipelines for the merge request, and the way the commits are stored for the merge request is in YAML, which means that we can spend 60% of the time during that page load, just deserializing that YAML. That's not querying it or fetching it from the database. That's just taking the YAML we've got from the database, figuring out what the objects are, and then going back and asking the database for things belonging to those commits. So making this a real table is tricky, and the migration will be tricky as well, but hopefully it will improve load time quite a lot on large merge requests, because at the moment, if you have a large merge request and you add to it, it gets slower as you go, which is, again, a really bad experience. And finally, released issues will be there. It's in master. It's definitely going to be in 9.4. So I definitely won't be talking about that next time. I'm going to stop sharing my screen now to see if anybody's got any questions. Rebs asked if snippets can be versions soon. So, yeah, one thing that would be awesome is if our snippets were Git repositories, like GitHub Gists. I don't think we have any plans to do that at the moment, but it would let us do things like have multiple files in the snippet, or, like you said, versions of snippets. But I think the improvements you have just made, we'll see if we can get on to that sooner. I'll give everybody 10 seconds for other questions. Otherwise, go enjoy the sunshine, at least if you're in Europe. Okay, great. Have a great day, everybody.