 So welcome to the kickoff. This is gonna be a great, awesome release, the best release ever. And the reason it's the best release ever is because it's our 10-0 release. So, and we have 10 fingers, so that's a big deal. And so as usual, the release post draft is already up online as a WIP. So please visit and see all the great features we already have there in the release post. And of course, that's gonna be finalized once we ship 10-0. On the discussion side, we're gonna keep working on performance as with many other teams. It's very important for us. And so you can click on that link there to see many of the issues that we are working on or planning to work on in 10-0. Another big area that we wanna drive forward on discussion side is increasing usage for some of our, you know, flagship features and that are very important to the platform. Going forward in particular, service desk and issue boards are two areas that we wanna focus on and get more users using it. A lot of, it turns out a lot of our users don't even know about issue boards. And even though it's been around for close to a year. And service desk, of course, is a lot newer. But again, we wanna increase usage. So those two issues are links there. You will see we have some great designs to push people or just to educate them, let them know what are issue boards and in particular, service desk. It's a little bit harder to tell people what it is in the first place and then to get them to ask their users to use. So there's two layers of communication there and education. And we wanna just start with the very first layer to get our existing users to understand what service desk is. We wanna make a big splash in the gerus side. We understand many of our customers are coming to GitLab and they wanna use a GitLab merge request but they're still hanging on to Elastin and Jira. So we wanna make that transition very easy for them. So if you've ever used Jira before, you know there's something called a development panel which you can see pull requests or merge requests. You can see commits and branches right inside a Jira issue or a Jira ticket and you can click on it and then you go to the associated branch, commits, merge request on and so forth. So we're gonna start doing that inside Jira in the upcoming release. Again, to make that transition seamless. We wanna start commenting on images inside merge request diffs. I know that's being mentioned other places in this kickoff as well, but just really quickly we want to take our code review and move beyond just text review. So everyone can contribute and it's not just code, it's images, it's assets. We wanna keep moving forward with moderation. We now have the ability to report abuse in issue descriptions and comments and our next feature is locking down issues. So if you start having a flame war or people are being abusive in a particular issue, comment right, we wanna lock that down very easily. Group issue boards is huge. It's gonna be the biggest thing since project issue boards. Again, which I mentioned was released just about a year ago and I think I mentioned this on many kickoffs already. A lot of our users or customers are asking for group features. They wanna move beyond projects or projects is not good enough for them. They want team-based workflows and in the GitLab world, that means leveraging groups. So group issue boards is gonna be a huge feature. Many of our customers and users have been asking for it. And finally, Slack is something that we've been working on. We have users able to go from GitLab.com to Slack with one click as of 9.4 and with 10.0 we wanna do the reverse flow. We're talking to the Slack folks as well and they're very supportive and they're gonna help us in terms of marketing efforts and in terms of telling us what their users want. So we're gonna run forward with Slack and the first step here is just to complete that flow. So if a user starts inside Slack, they can find the GitLab app in the Slack directory, click a button and then go directly to GitLab.com to go to our landing page and add the feature there. Fabio, you're up. Fabio, you might be on mute. He's on vacation. Oh, okay. Yeah, he actually joined the call but he's in need of an application and he said if like his internet broke up or something, I had to take over. So I waited a bit. Anyway, I'll try to do it as enthusiastic as he does it. I'm likely gonna fail, but I'm gonna try anyway. So we're beginning with Autodev, one of the Autodev ops, I'm sorry, it's talking too fast already. It's a direction issue. It's a huge issue. Cit wrote up a whole bunch of points which we want to address, but basically it comes down to, you basically wanna write code and everything else. GitLab, as far as we can, we should take care of it. We're gonna push this forward. Next thing is we're gonna show you HTML in the browser because browsers run the HTML, who knew. Then security, so protective runners. Let's say you have shared runners. There are ways that you could leak confidential information. For example, variables. We try to hide them as much as we can but we can't guarantee that we actually hide them because for example, you could email them to people. Now what you can do with protected runners is tell the runner that he can only pick up jobs from protected branches. So we're linking these now, which gives you a way to secure everything, at least like the variables and the whole environment where you execute your test code deploy. The second one is runners. You can lock them to projects and this will be the defaults. Now the next point performance like Victor said, we will also as a team focus on this. Yeah, Jorick came up with, not came up, but his measurements show two slow controller actions. One is job show and the other, I don't know by heart, but two will pick out this release. So now I'm in the dark for one of them. Use configured endpoints in runners. I'm sorry, I didn't read up on this one but I'll invite you to click on it and per projects pipeline numbers, that's basically for everyone who develops and get lab IIDs for pipelines because now for something to merge request widgets, you'll see an ID of your pipeline, which is this crazy long number and it has no meaning for you or for someone else because it's the ID. So if I create one in my project and someone else I don't know creates another pipeline in his project that increases my counter for the ID as well. So we will have ID scope to a project. This is gonna be huge migration. So this is gonna be interesting. And then there are two bug fixes as well. So basically if dependency is not met for a job then it will just fail, seems reasonable. And for subgroups, you can't have get lab pages because of the way we store pages in the pages daemon, but we do show URLs for subgroups. So we're gonna hide that. And then over to Josh. Thanks CJ. So I am super excited about 10.0 in particular on the Prometheus items here. We've got a lot of exciting features that come up and kind of round out some of the work that we've been doing here the last couple releases. The first one is that we're gonna go ahead and enhance our support for charts and multiple time series. And so right now you can get some really awesome charts around response times and request throughput, but we can't quite display, for example, the request throughput broken down by response code. And so at 9.5 we'll be able to do that which is really exciting. And we'll also be able to get some colors on there for the individual series as well so we can get some sort of distinction between perhaps 500 codes and 200 codes, red versus green, you know, has some kind of instant kind of recognition of which one's good, which one's bad for charts that makes sense. Next up, kind of building on top of that as well, we're going to be adding comparison of Canary versus Stable. So if you're doing Canary style deployments where you have sort of version.next deployed in a controlled way in production, say 5%, 10% of your fleet, we'll be able to actually gather metrics from that and compare it automatically against your kind of current version or GA version as well. And that what we can tell you, you know, is a response time going up, is it going down? How is your request throughput going? There are error rates and things like that. So some really key metrics there on our response metrics will give you nice clean comparisons between Canary and production and give you a good idea of if you should go on and continue to let that Canary roll all the way out through all of your production notes and become the new GA version. The other big item we got here, the Pythias side is to attain parity as far as metrics goes with the existing inflex DB based system. So we've been kind of working on this for a while, laying the foundation, building kind of some way, a way to instrument Ruby code with Pythias metrics. And this is gonna be sort of the big step here where we, because of hit parity with what we have a fourth inflex DB, plus we have some extra stuff as well. And that will then allow us to deprecate inflex DB here as part of the 10.0 release. And that'll be really exciting to hit that metric there in that bar. And we'll of course continue to push ahead and instrument additional areas, but at least we'll have parity again with what we had before on the inflex DB side. So that's the exciting features we have coming on the Pythias side in 10.0, super exciting. And we can now transition on to the build side where we're gonna go ahead and have our first standalone chart for sort of our new version of Hellman charts. That'll be available for the container registry. We're actually already running sort of standalone version in production on GitLab.com today. And we'll be bringing that to our sort of cloud native repository of our new standalone charts that is not based on the omnibus. So could have a kind of new cloud native deployment model which we're driving towards here on the build side. So very exciting there. We'll also be making some improvements to the GitLab sort of HA and service HA. So with this, we'll go ahead and make it easier to deploy the application nodes in an HA fashion and improving some of how that works and the configuration required to get that done. And then in keeping with a theme of 10.0 and a big major release, we'll also be working towards removing support for Postgres 9.2. We've had it for a while. We've been actually sort of migrating everyone as they have upgraded to the 9.x series of releases. And 9.2 in this case is actually going end of life on the Postgres side in September, which of course when this release will be shipping. And so to coincide with that as also along with the 10.0 release, we'll go ahead and remove support for it. And this will make room for the 10.0 support which you're excited about as well on the Postgres side in the near future here. Last on the build side, we're gonna go ahead and do some work to simplify and improve the omnibus package installation. So our goal is to have a single command that you can run to go ahead and download the package, install the package, and then also pass the required main bits of information, mainly the DNS name directly into GitLab. And so we can reconfigure it all in one shot as opposed to having you execute separate commands, edit a file to pass right DNS name and then reconfigure yourself. And so again, really excited about this, make things easier to install GitLab and as well as lead the foundation for some other exciting features that are coming up around things like supports for less encrypt on the SSL side. So again, can't be more excited about 10.0, best release ever. And until you might talk about how exciting the platform priorities are in our 10.0 release. Josh, thank you very much. Firstly, apologies to everyone I'm having to join via mobile phone from the middle of the Alps because the lightning storm has basically taken my internet down to 1996 internet speeds and it's not basically viable to join via the internet. Anyway, let me move on very quickly with what we're doing in platform. I guess once upon a time there was a release called 9.6 and release 9.6 had a younger brother called release 9.4. And in 9.4 we started introducing via a feature flag our new navigation to GitLab and in 9.4 and 9.5 we've been improving that and listening to a lot of feedback and the entire UX team have basically been heads down in research and design and really trying to come up with a better way to navigate and understand where you are in GitLab. And in 10.0 the new navigation will be the default and the only navigation release to everyone and from everything that we've seen so far and starting to do an amazing job at helping people navigate and understand GitLab's hierarchy a lot better and we're really, really excited for this and this was one of the primary reasons that 9.6 got renamed to 10.0 was because GitLab will look very different in 10.0 and there's some great other features coming out in addition to what people have seen today in particularly 9.5 as well, a lot of improvements put in 10.0 will really be putting the finishing touches on the navigation and we'll be bringing back the ability to customize your theme of GitLab. So if you don't like purple like we all love purple at GitLab you'll be able to change the appearance of the sort of top header and some of the sensing on the left navigation to some other colors. So this is really exciting. It's been an amazing effort from just multiple teams and multiple people and we can't wait to ship it. Next is where in the platform team we're really putting a doubling down on our efforts on performance. In every release we're introducing performance improvements but in 10.0 the platform team are going to be tackling probably two to three times the number of performance improvements. So this is making pages faster, making projects, create quicker, making commits happen faster and then relate to two performance and the one feature that will be coming out is effectively a performance and availability. Management feature is going to be an EE feature which will allow people to store LFS files in object storage making sort of large installations and large LFS implementations of GitLab easier to manage through effectively connecting it to object storage. So this is just building on some of the great work that the CI team, CI slash CD team, sorry, have been doing on artifact storage in object storage. As everyone probably knows, we introduced subgroups in 9.0 and we've been continuing to improve those. One of the big blockers for people adopting subgroups is subgroups allows you to manage GitLab in a better way by structuring your projects better but a lot of people have locked down the ability to create top-level groups and this also means that they can't create subgroups either and sort of delegating that ability to other people in the group to allow them to create subgroups and create some structure so the administrators are not having to do this all the time is a sort of welcome addition to subgroups. So this will really be a big improvement for how people use subgroups allowing other people to create them and then sort of somewhat related to that just inheriting some of the share locking capabilities. I'm taking up probably too much time here but we are improving some of that group sync capabilities which is a GitLab Enterprise Edition functionality just allowing better synchronization at login and via the API. And additionally with the internationalization effort we've been doing, we are adopting a platform called CrowdIn and CrowdIn will basically be the source of truth and where we accept translation merge requests coming from the community. They have some amazing tools to allow people to contribute, to suggest, to vote on internationalization and translation strings so we're really excited to be working with them. And then finally the little surprise is we're going to start to work on a GraphQL API and this will be done in an experimental way with the EmojiQuest widget and this was really exciting but it's probably a slightly more long-term investment because it'll take us quite a while to get to a full GraphQL API but we're really looking forward to getting stuck into that technology. So that's far too much of me and over to Jacob to tell us what's going on in front-end DC land. Thanks so much, that was a great update. So in the front-end DC land we are doing a lot of things that Victor already talked about. We're trying to improve the discussion capabilities from the front-end side. One major thing we're going in the direction of is helping people with their visual assets so we're gonna start by commenting on images and commenting on a specific coordinate on an image so that we can start to have comments on images and specific comments on a specific point on an image which is really exciting. We have the ability to lock issues and the ability to move issues to a different project using the sidebar. So we're starting to add a lot more stuff into the sidebar which is very exciting. And finally we are doing a couple of proof concepts and one of the things we're going to push forward to get into 10.0 is the repo editor which is technically platform but we're gonna finish it anyway. So we're crossing the boundaries of front-end. Tim is not here so Kushal will reach with him. Thanks Jacob. So on the front-end AC side we have different performance improvements around the platform and the Prometheus side as for the performance improvements for the platform we already had lazy loading for issues and merge requests in in the 9.5 so we'll improve around that. We also got the inline JavaScripts removed so we will improve on how the page load can be improved by removing any additional JavaScript that is blocking the first view. Then one of the big plans that we have is to upgrade the jQuery because right now we are using jQuery 2.x release and it is a bit heavier compared to jQuery 3. So we'll have that upgraded as well and then we'll unify the way Ajax requests are handled. So right now we are using a couple of technologies so we'll probably unify those into a single API that can be used to perform Ajax requests so that could help as well in improving performance. Yeah, so that is it from the front-end AC. On to the UX, Sarah. Awesome, thanks. So the navigation, we're still working on some of the finishing touches. We've got a lot of great feedback from the community. Thank you to everyone that chimed in and let us know what they liked and didn't like. So there's a lot of calls to make the color customizable so there's an issue that we put forward to that. I think we'll start with three or four different color schemes but feel free to jump in and suggest what you'd like to see. We're making improvements to the collapse sidebar and adding drop-down links to the global links in the header to make it easier to get in and about. Continuing improvements to the breadcrumbs. We've had a lot of feedback on the breadcrumbs so we have a large issue dedicated to looking at how to make those less dense and easier to quickly see and navigate. Moving on to improving perceived performance. So we're introducing skeleton loading in different areas. We're starting with issue boards and that will help with just loading time and kind of how you perceive the page being loaded. Making projects and features visibility settings less confusing, this is a huge one. Take a look. I think that a lot of you will really enjoy the differences that have been made here. Lot easier to just quickly understand what settings you're actually using. And then making search boxes consistent throughout GitLab. We're going through and making everything more consistent from drop-downs to our hover states and right now we're working on search boxes and making sure that those deliver a consistent experience all through GitLab. So it's just some of the stuff we're working on. Stan, what are you working on with Geo? Great, thanks. 10.0 will be awesome. We are doing a lot for Geo to make it production ready. And so that's really a theme for 10.0 if you don't take anything away from this. One of which, the first item is start testing Geo with gitlab.com or some small example of with a database that big with some small repos and things like that. We've been talking a lot about deprecating system folks and we've done that, but we need to remove them. So 10.0 is a good time to just nuke them completely. There's a bunch of items that we need to do before we can do that. And then we got to start measuring how quickly are we downloading things? How long does it take to actually schedule something? So that's part of production readiness and getting the data we need to understand how it's behaving. There's a feature that's in work right now to we have a legacy way of storing projects on disk and we're moving to this hash base format so that every project sort of retains a permanent directory on disk so you never have to rename things. And so we're gonna need to figure out how do we actually migrate to this new format? So whether we need to have an API, how do we do this in bulk? How do we monitor for all those migrations? And so that will go into a lot for 10.0. And then finally, one of the things in no care is just having a better testing tool so that we can exercise geo in a way that our users may be using it and catch a lot of problems before they actually become issues. So that's really geo in a nutshell. Thanks everybody for a great kickoff. I think 10.0 is gonna be really, really awesome. I'm really excited to see all this new navigation on my default and all the great features coming down the line. So anything else anybody wants to add? Best release ever indeed. Great, thanks everyone.