 Hello everyone, welcome to this new HTML date. I'm Remy and the HTMLid. And today we'll go with the same agenda as forever updates. So what we've done in the last five weeks, what will be done in the next five weeks, the current lowlights and you will have time for. So let's get started. So Mark Fletcher made a great landing page for the issue bashes. So it contains everything that community members need to know to get started with the issue bash. So I prefer to check it out and improve it. Then we, so Shinya was a very active contributor in the last few months. And so it was actually the 9.2 MVP. And we considered to invite him to the core team, but unfortunately we hired him before. So unfortunately for the core team is no part of the GitLab Inc team. So we are still super happy with that and welcome Shinya to the CICD team. Next, we accepted some really nice community contributions as always. So I won't go into each one of them, but here is a non-exhaustive list of the most, yeah, the biggest ones, let's say. And we also had a lot of documentation fixes from the community. So that's always great. Next up is regarding the quality. So we are always enabling more Rubocop. So Rubocop for the one who don't know it, it's a static analysis tool. So it's analyzing the code base and it reports offenses to the cops or the rules that are enabled. So this time we've enabled a few spec-related cops and security related one also and style consistency cop. And we are always adding more and more. Then we're getting the productivity. So the HGM is one of the focuses to improve the productivity of the other developers. So as you may know, we have a lot of transient failures in our test suite. So it's an ongoing effort to fix them. We fixed a lot of them. A big shout out to Luke Bennett. He was very involved in solving them in the last few weeks. We also identified a failure that we had in the CI. It was an out of memory failure. So hopefully it's fixed. It was related to a WebKit issue. Then the next one is we sped up the booting of GitLab, the Rails app, so approximately by 50%. Thanks to a gem developed by Shopify, an open source gem. So that's really great. And we've also started to work on scripts to streamline the developer's experience and to have a consistent experience between all the GitLab projects. Basically you will have like scripts in a script folder to bootstrap the project, set up it, insert, record in the database and stuff like that. So Jorik did a great job to add a lot of documentation regarding the changes about. So as you can see, it's related, almost all of them are related to active records or the database somehow. So basically the thing is that as GitLab needs to scale more and to be more performant, we have to kind of leave the Rails way of doing things like we are going away from using the CELAS method from active records where we are going to use actual foreign keys for the database. And we are also going away from polymorphic and single table inheritance. So the first step in doing that is to have a great documentation to know what are the alternatives and the new ways to do that. So thanks Jorik a lot for that. On the development side, so new features, Mark, Fletcher contributed an events API because it will be needed to analyze the issue batches contributions basically. So we now have a quite useful events API. Thanks again to Jorik, we also will be also able to perform background migrations. So basically it's migrations that will be run as side kick jobs to submit up. And another feature is the introduction of a performance bar. It will be behind the feature, but basically you will be able to profile the current page to see the SQL queries, but also the queries made to radius and profile the code base with Ruby line profiler. So that was for the last five weeks. In the next five weeks, we'll work on speed up the test suite. Robert is working on that. So, but yeah, in the last weeks, Robert has worked for a few other teams like the projection team. So I hope that he can focus on that more. And I'm really looking forward to seeing this trick about the signing way. How to say that, basically it will not perform a real signing in the filter specs. So instead of going to the signing page, fill the form and submit, it will just sign in the user straight away. So we'll save a few seconds for each filter spec, maybe not a few seconds, but even a few milliseconds will add up in the end. We're going to replace Poltergeist with Chrome. So basically it's the headless browser that we are using for specs. We had quite a few issues with Poltergeist, including the memory, the out of memory failure that I mentioned earlier. So we are hopeful that using Chrome will solve, will improve the situation. We'll continue to enable more Cops, RuboCops for the code quality and security and stuff like that. And then we'll streamline the developer plans with some scripts as I said before. And we'll provide a way to seed millions of data in local environments for developers to actually see how that code behaves with a lot of records. It will not be the same as a real staging or production environment, but still it will already come closer to that. We'll also automatize CE to EE upstream merges. There's already a magic quest that kind of works, but it still needs tests. And a lot more things in the pipeline. So we'll be to check it out. Lowlights, as always, we still have a lot of red masters because of changes of values. So we'll think about a way to detect and retry those. So we'll see, but basically the idea is, there are a few ideas, but we could detect them. And as soon as we know that they are transient, we could allow a pipeline to pass. If we know that the test is a transient failure, but it still will need to be fixed in the end, of course. Or we could just try to retry the test in a different context, because most of the time it depends on the context, like the test that ran before the failing test. We still, so yeah, upstream merges from CE to EE, still takes a few days, most of the times. So the goal is to have a daily merge, but most of the time it takes more than that. So we need to better separate EE from CE code so that we have less conflicts and less test failures when we merge CE into EE. And the test with duration is not stable. NAPSAC is the tool that we use to balance the test across multiple nodes on the CI. So it's doing its job, but we suspect that the culprit could be that the runners are under loads and it means that this can take more times in certain situation. And yeah, that's it for today. If you have any questions, I will be happy to answer them. I saw a question in the chat at the beginning. Do we have the new code climate enabled? I'm not aware of that, so I cannot answer these questions. I can answer this question. Yeah, not yet. I have a merge request still open, but it will take few days. So in order to have it fully working, we need to have masteries, got climate jobs completed. And now I just waiting for a green master in order to have my merge request ready. So soon in few days, thanks Remy. Yeah, as soon as we have a green master before a few days, a green master, of course. So, okay, I don't see any more questions. Feel free to let me know if you have. Remy, will users be able to enable the performance bar? Yes, so yeah, the performance bar will be, you can enable it with a shortcut. So the shortcut is PB for now. And yeah, every logged in users will be able to enable the performance bar. Cool, and if it all works, we'll remove the feature flag in 9.4. Yeah, exactly. Awesome, thanks. Cool, you're welcome. Thank you everyone and see you in the team code then.