 Hi everyone, it's 4pm by my clock, so I'll get started and I'll just share my screen. I'm Sean McGiven, I'm the lead of the discussion backend team at GitLab. We deal with issues, comments, major quests, notifications and things like that. In the last five weeks, we've just had our feature freeze for 9.1, which was on Friday, the 7th of April. We made some great changes in that time. Issues and MIR index pages got a lot faster. I think this was actually in 9.0, but I didn't have charts at the time, so I've included some charts this time. You can see that when you're viewing the dashboard of issues or major quests assigned to you, that went from taking 20 to 60 seconds to taking about a second. Issue notes polling, when you're on an issue page, we poll the database for notes, comments that have been added since you noted the page so you don't have to refresh the page. Now, roughly 70% of the time that doesn't hit the database at all, instead it just hits Redis and Unicorn, our Ruby web server. So thanks Adam for that. We're working on getting that to other pages with comments as well, but it's more complicated for, for instance, merge requests than it is for issues. The GitHub importer that people can use to move a project from GitHub to GitLab, either gitlab.com or their own GitLab installation is now more robust. We've fixed a lot of edge cases. It's much faster and more efficient at fetching the data it needs, and it can be run through rake instead of sidekick, which is kind of a technical consideration, but basically means that you have a way of controlling the environment that it runs in much better. And that's been a bunch of people working on that, Douglas, James Lopez and Gabrielle have been working on that. That's been really awesome. We also shipped some features. Burndown charts are in eStarser, so those are for using open data and closed data on issues and using the start date and end date of a milestone to show you how you're progressing. I'm personally not a huge fan of burndown charts, but some people love them. We also have service tests will be in 9.1, the first iteration of that. That's an e premium feature. It basically lets you email issues to a project, which you can already do in GitLab, but without having a user account. So if you want to provide support to people who don't necessarily have accounts on your GitLab instance, they can email issues in. They will be made confidential and replies will go to the person who emailed them. It reuses a lot of the existing concepts we have in GitLab for permissions who can do things, who can see things, for spam checking, for subscribing to things. So it's quite neat. It is unfortunately quite hard to show in a screenshot. So the screenshot there is just me with a test issue, test service desk issue. But that doesn't really show what it's about. And Janine did an awesome job on that. And then Felipe helped get it finished, which was really great. In 9.1, we did have some things that weren't quite there. So multiple assignees for issues didn't quite make it. The biggest reason for that was we just didn't have time to review it, make the changes from the reviews. Review again, you know, go through that iteration in time for the 7th. So we decided to pull it out before the 7th so that we knew that we weren't trying to rush to get it in. It's a big change. It's fine for that to move along and it's going to be really awesome when it gets there. We're backporting the usage ping to CE, which isn't really a discussion thing, but the Edge team has not many people on it. So we're helping out all the new features that will incentivize people to have the usage ping enabled in CE are now in E. And we will make sure that they're backported to CE for 9.1.0. We still have some performance issues open, which I would really like to get fixed. Issues and merge requests showing those can be slow. Also milestones can be slow to render, which is a problem because we're adding burn down charts, but it's also a problem because we have a trace of the SQL queries that are run by that page and it's 1.7 megabytes, which is way too big. Basically, it's crazy. So there's definitely some big gains to be had in making the milestones render a lot faster. The merge request widget refactor is happening, but it's not quite there yet. This is mainly a front end thing, but we're helping out with the back end for that. That's to make the merge request widget use view instead of be rendered by the server, which means that we won't have all these weird states that we have at the moment where part of the widget is updated because the server sent new display for that, but not the other part of the widget. So you get things like buttons, half in one color, half in another color. Part of the widget is telling you something's passed and part of you telling something it's in progress. So that's going to be awesome. In 9.2, we're going to finish multiple assignees for issues. We're going to start working on relationships between issues. So we already have cross-linking when you reference an issue and another issue, but we're going to go a bit further and add an explicit relationship for those because that's something people have been asking for for a long time. It's supported by a lot of other issue tracking systems in different ways. Some have specific types of relationships, other ones have customizable relationships. So it might not have any by default, but you can add your own blocked relationship or whatever. We're just going to start with a simple relationship and then look and see what we're going to add in future. We're also going to make our public API able to do everything the UI can from merge request diff discussions. So at the moment, we have these like resolvable threads when you add a comment to align in a merge request. And in 9.1, you will be able to start a resolvable discussion from anywhere in a merge request or an issue or a snippet or a commit. And the API doesn't support any of that at all. So that's only available to people using the UI, which is really unfortunate for integrations and it's a gap that we should fill pretty quickly. We're also going to finish some work that Yaka started before she even joined GitLab, which was awesome, which is to allow commenting on personal snippets. So at the moment, all of our comments are tied to a project and personal snippets aren't because they belong to your user. So we need a way of making comments work outside of a project context. But that's going to be something we're finishing 9.2 as well, which is going to be really great once that's done. And in future, just put two refactors or technical debt type things here, but they're quite important. So we're going to refactor notification settings at some point. So it's going to unblock. If we want to add a new notification type like we did with pipelines, often they shouldn't auto subscribe people who already had existing notifications settings sets because then people start getting extra emails from GitLab that they're not expecting and they are quite unhappy about that. So the way the code is at the moment makes it quite hard to do that. So we're going to try and make that easier. And then we're also going to try and make it easier to remove data that GitLab needs. Because we have two sources of truth, essentially for GitLab, we have the Git repositories, which store all the code, and we have the database which stores all the comments and merge requests around that code. And we need to link those two in some way so that we can say when a commit is removed, we can also remove the merge request associated with it or equally when we remove the merge request, we can remove the commit. At the moment that means that people have issues where if someone pushes a big change in a commit and it's added to a merge request, even if they remove that commit, the storage will still be used. So they can never reclaim that storage unless they the administrator does something manually. And equally, you'd have the same situation, not with not necessarily a problem with size, but with sensitive information if you accidentally push something that you didn't mean to. You can remove that commit from the repository locally, but you can't remove it on the remote GitLab ends if it's been mentioned in a merge request or in some other places as well. So yeah, that's what we're working on. I'm going to stop sharing now and see if anybody's got any questions. Your Basque's way we didn't ship the performance improvement from Milestones. We won't try it for 9.1 still because we've stopped developing on 9.1 will try it for 9.2. We probably could include it in the RCE phase for 9.1 but I'd much rather include as few changes as possible or in that phase. I think it basically did boil down to capacity. Basically everybody had something specific to work on and that didn't get through, but I think that's a really, really obvious important thing that we need to fix. Okay, I'll give everybody 10 seconds on my phone to ask more questions. Otherwise, you can go enjoy the rest of your day. Well, you can go now. Five seconds. Okay, we're done. Thanks everybody.