 htmlid update. I'm Remy, htmlid, and today I will speak about a few things. So let's start. First off, I want to welcome Pacquiao Nogushi to the core team. It was a long process to have him join the core team. We even got to create a confidential issue to get his attention, but it was just that he was very busy and didn't see all the emails we sent him. So yeah, very, very glad to have Pacquiao in the core team. He's been very helpful in issues and contributing great stuff. So that's super cool. In 10.2, we merged 55 major quests from the community. Feel free to check out the spreadsheet. I highlighted two major quests below. So the first one is from Jacobo, who is a seasoned contributor now. So it's a Robocop rule, a static analysis rule to improve our code base. And that's super cool. And the other one is from George Andrinopoulos, who also submits a great backstage and technical depth solving major quests. And this one is about creating new services to encapsulate the the destruction of issues and magic quests. Thank you. Okay, the next stop is in the performance front. So as all the teams, all the backend development teams in general at GitLab, we worked on improving the performance and this quarter. So Genshin in particular worked on improving the branches page performance. So I think I mentioned that in the last update, but it wasn't yet deployed, basically. So now it's being deployed as of 10.2. And the improvement is 25% approximately. So that's great. And Genshin didn't stop there. There's a second improvement that will come in 10.3. And we even have more improvements in mind for the future. So thanks, Genshin. And yeah, this will, this will even improve in 10.3. Triage automation. So I mentioned that in my last update too. So Triage automation, so Mark is working a lot on the new GitLab triage project, which is a gem that you can use in any project in GitLab. And we are actually already using it to automatically triage GitLab CE issues, as well as GitLab Runner and GitLab.com support tracker. And we even had Alessio from the CICD team that contributed a new feature that was needed for them. And yeah, you can use, so it's a gem that you can very easily use in your pipelines. You would just have to define your triage policies in a YAML file. So very similar to a GitLab CI YAML file, basically. That was one of the Q4 key results for us. And we still need to document it and to communicate around it to really maybe this more known feature. Yeah, definitely. We really need to communicate on this because this is a really powerful yet simple project. And that's really, I think that's really just the start. There's a lot of features that we can add to that and improvements. So yeah, we'll definitely do a good first. GitLab QA. So as I also said in the last update, GitLab QA is getting a lot more love lately. So we started the documentation just with a visual explanation of the GitLab QA architecture because GitLab QA is actually a few things. It's a gem. It's also there's also a part in the GitLab CE and EE projects. And there's a lot of Docker images involved too. So it's great. At least for me, it was great to see it visually. So I hope that can help others. And then the build team presented the training on GitLab QA. Thanks, Jan, Jan Baum from the build team. So the video and slides are available. It's really useful if you want to contribute to GitLab QA as well as understand how it works. So yeah, there's a lot of activity in GitLab QA. I've contributed a scenario to test additional upgrade from CE to EE. So it's very basic for now, but at least it checks that you can upgrade from CE to EE. Then Grigorz improved the package QA job, which was called something else. But anyway, now it's called package QA. So it's a manual job in every GitLab CE or EE merge request. And if you play it, it will trigger a pipeline in omnibus. And then in the end, it will run the QA scenarios. And what's great now is that the package QA manual job that you played at the start in GitLab, in your GitLab CE or EE merge request, will now wait for the QA scenarios to actually finish. And that was not the case previously. So it was making the job a lot less useful. So now it's great because if your merge request breaks the current QA scenarios, you will have the feedback in your merge request directly. So just keep in mind that this job is still manual because the QA, the whole trigger through omnibus and the QA scenarios run are quite long right now, still a bit long. And we are not sure we want to just enable it by default for omnibus request. But yeah, we have a plan to make GitLab QA production ready. Thanks to Gregorz, who is a lot involved in GitLab QA. So there's a lot of improvements there. Testing, so testing as you can see, I didn't talk about testing yet. So that means that it's getting better. So I checked and we had only 11 test related merge requests in Thunder 2 probably. I didn't check the link but in the last few weeks. And what that means is that we have a lot less transit failures for a few weeks and even months now. So it's really good for the productivity of the team in general. And I think that's because of the retries that we do at the example and job levels in the CI. But I think that's also due to the new high CPU runals that we are using. And as you can see in the graph, the test runs are a lot more stable than before. If you look at my old days from a few months ago, you can compare that it was going like up and down. It was not stable at all. So right now it's very stable and at least that's cool. So yeah, last time Cid suggested to me we could use preemptive instances and parallelize even more because of the cost cut. So I've created an issue and it's still discussed. Apparently it's not coming tomorrow but that's something that we should keep in mind. And then, yeah, the best at the end. So we now have a script to automatize the CE to emerge. And that's a script that you can run manually if you want. But the point has always been to run this script in a CI pipeline, scheduled pipeline. So right now we run the script automatically every three hours. And what it does is it's merging CE to EE and it gathers the conflict. And it will then it just push the branch. It creates a new merge request and it pinged people to resolve the conflict, to help resolve the conflicts. And that's great. And yeah, if there's already a merge in progress, obviously the job will not create a new merge request because it would be useless. But yeah, that's really useful. The people that are involved in the daily CE to EE merge request are really liking it. If you look at the CE to EE channel in Slack, we'll see. And yeah, there will be some improvements that will come shortly. The first one will be just to post the link to the created merge request in this channel in Slack. And also probably to assign the merge request directly to the first person that has to resolve the conflict. And then the person will assign to the next one in Slack that has to resolve the conflict. So yeah, that was it. I'm really excited about this automatic CE to EE merge. That was a long, very long needed improvement. Are the QA video and blog linked from somewhere, for example, the docs? That's a good question. I don't think so. I'm not sure we should ask the build team and maybe Jan in particular, but I will make sure it is linked from the documentation, definitely. And yeah, how do you see the number of merge requests? Yeah, you notice that it's declining. I noticed it too. So I think there's a few things to note. A few months ago, we had a lot of merge requests for internationalization. And that was so now it's been externalized basically to the crowding service. So we have a lot less community confusion for that. So that was kind of, I mean, we could probably count all the contributions like the translation contributions in crowding. We could count them as community contributions because they are. But unfortunately, there are not content in this graph. So that could be a reason. I think it makes sense to look at the code. It's great that we have crowd-source translation, but we have crowd-source translation. I think we can leave it at that. I think we should look at the unique offers of code that got merged every month. Yeah. And yeah, I think maybe also the teams, I don't explain 100% the decrease, but maybe that's because our teams are more busy on features for GitLab and have less time reviewing community merge requests. That being said, I think the total number of community merge requests that are open right now is kind of stable. And I checked yesterday, we have also a lot of work in progress merge request in the community. So yeah, I'm not totally sure why it's decreasing. Do you think the number for December will still go up? Yeah, for December, yeah, it will go up. It will still go up a bit, but not a lot because we're already the 5th of December. So yeah, I'm not sure about that. Okay, thanks for the context and hopefully we should make it a bigger priority to focus on the request coaching. Yeah, yeah, maybe we could do that. Yeah. So Tony is asking, can we exclude the previously translation from this chart? Yeah, we could, but I don't know if it's worth spending time on it, but yeah, we could. I think you are looking at the closed ones. Yeah, they are 39 merged. But yeah, thanks for all your questions. I think if there are no more questions, I will give you back 12 minutes of your time and see you in the team call. So yeah, thanks everyone. Thanks, Hermie.