 So since I last did an update, we've had an 8.17 release, but because we also changed our feature freeze process to only include actual regressions during the release candidate phase of the release, we are also almost at the stage where we are freezing 9.0. So in 8.17, the main thing we shipped was squash for merge requests and then we had a couple of patches to fix things for that. In 9.0, which will freeze tomorrow and will be, sorry, will freeze after tomorrow and will be released on the 22nd of March, we're gonna be shipping reordering issues in issues boards, which is gonna be awesome. So that was started off by Dower and then Valerie and Phil have been working on finishing it. We've got version four of our API, which is also awesome because it lets break a lot of inconsistent or confusing or bad behavior in the V3 API and mark that for deprecation. So that'll be removed soon. So Osvaldo, Tone, Robert and a bunch of other people have been working really hard on that. We've also been working on some performance improvements because of the amount of breaking changes we haven't got to as many as out of light. But we do have three there from Felipe, Yaka and Adam that I hope will improve performance. We believe they will, but we haven't actually deployed a 9.0 release candidate to gitlab.com. So unfortunately, I can't show a chance from the monitoring for that. But we do believe that there are decent improvements to the issue and MR index page in general and also to the dashboard where you can see all the issues assigned to a particular user or the MRs assigned to a particular user. And there's also an improvement to notes polling when we're loading new notes as you come in on an issue page. Things that didn't go so well in the last release and a half, we were working on a license finder feature for EE, but that turned out to be way more complicated than we realized. It needs basically to run in a CI environment, but to make it a good feature, we need some auto configuration stuff that's kind of tricky as well because the license finder gem that we use, first of all, when it figures out for Ruby dependencies, it will actually evaluate your gem file, which is a bad thing because then people can run whatever code they want. But also it can shell out to different package managers for different languages rather than just implementing the parsing of the dependencies in Ruby. So that was gonna be much trickier. We would also need a way to get the results back from CI in a good way and display them nicely in the UI. So it's actually working on a different feature, which is service desk. Because we started that later in the cycle, that means it'll be finished later in the cycle, so it'll be ready for 9.1 instead of 9.0. And again, I'm gonna blame something else on the breaking changes because we had a lot of those. We've spent much less time fixing bugs, so we fixed bugs that are regressions, but we haven't fixed bugs that are just existing bugs that I would like to get fixed, which is very frustrating for me as a lead personally because I have a list of issues that I care about, which is mostly bugs and that has been growing during this cycle, so I'm really hopeful we can get some of those done in 9.1. Speaking of which, the main things we're looking to ship in 9.1 are service desk, which I just mentioned. We're gonna work on multiple assignees just for issues to start with so that you can assign multiple people to an issue, which will, at least for us, solve the problem where you have an issue with someone from the back-end team and someone from the front-end team working on it, and only one of them can be assigned at a time, so the other one has to just know that they're working on that issue rather than looking at a list of their assigned issues. We're not doing that for merge requests as a first step just for issues, and then we can go from there. We're also working on a burn down chart for EE, so we're gonna add a closed apps field to issues and then calculate a burn down chart based on that. It won't preserve the history of state changes, so if you add a closed issue to a milestone and then open it and then close it again, it will just assume it was opened on the open date and closed on the closed date. It won't care about when it was added to the milestone or that it was closed the first time, so it's quite a simple burn down chart to start with, but we can implement it like that and see how it goes. Also, the notes polling that I mentioned uses some middleware that Adam's written with help from, with design from Andrew, which uses eTags to only hit Redis if a resource hasn't changed, which means that we can be much more efficient when we're polling. If that goes well in 9.0 for the existing polling we have, we can look at doing that for issue titles. In future, I wanna schedule more bugs. I'm just gonna keep mentioning that until I get some bugs fixed that I care about. I still want to refact the notification settings, which I think I've mentioned the last couple of times. I think we're getting close to being able to do that now. Once nested groups is released in 9.0, which is from Dimitri, our CTO, mostly he's developed this feature by himself. We need to see how people use that and how people expect it, and then we can start working on group level issue boards. Also, I wanna help the edge team pick up and finish some of the community MRs that we have that have stalled. We have a lot of those in the discussion team. There are two merge request coaches at the moment, Adam and myself, and Oswaldo is helping out with some community merge requests and may decide who wants to become a merge request coach in the future. So those are the things we care about. I'm gonna stop sharing my screen so I can see if there are any questions. So Jim asks, does the V4 API allow better migration from GitHub? No, I don't think really our API isn't, I don't think it's designed to be deliberately incompatible with GitHub, but it's not designed to be compatible with GitHub necessarily, either it's, it's whatever works best for our application. And I assume that in this case, you mean people having existing things that hit the GitHub API that they wanna hit the GitHub API with instead. So yeah, we don't, maybe it will be worth documenting some of the biggest changes, but I don't think we're gonna provide like a GitHub API compatibility level. Tone asks, is multiple assignees, is something that our customers want or something that we want ourselves? And Demetri said it's both, which is entirely accurate. I think it's one of the most requested features on our issue tracker. It's been open for ages. It's got over a hundred thumbs ups, I think, which is a lot. And yeah, people definitely want that one. And Yobasks, if the live issue titles will be the first use case for the eTags live data approach. Yes and no, we already have notes polling and we're gonna use the eTags on that because then we're not adding polling, we're actually making the existing polling faster. But the idea is that if issue titles works well, then we will extend that to other things. So that was a few questions. I'm gonna take a leaf out of Dower's book and give everybody 20 seconds to ask more before I end the call. So 20 seconds has already started. 10 seconds left. I can show you my phone. That's 20 seconds. Okay, thanks everybody. Bye.