 Okay, let's get started. Hi everyone, my name is Rémi Coutable and the Edge team leads. And today I will present you the first functional dates of the Edge team. So let's get started. Okay, the agenda for today will be what is the Edge team? Because maybe not everyone knows the team. Accomplishments, concerns, plans and time for questions. So what is the Edge team? First one, so the Edge team was created in October 2016. And right now it consists of robots, it consists of robots, Mark, the robot spiker, Mark Fletcher, Christian Kudder, and myself. And for my information, please check out the Edge team page in the handbook. The focus of the Edge team are first of all, developers productivity and long-term maintainability of GitLab. So it involves improving the development work-run processes, but also improving the code architecture and so to keep GitLab secure and maintainable in the long-term. So for this part, it's mostly Robert and myself focusing on that. Obviously we are helped by a lot of other people at GitLab. The second focus of the team is community interface, including issue-triaging. So it's issue-triaging of community reported issues and future proposals. And merge request coaching, which involves reviewing, helping community members to finish their merge request and sometimes finish the merge request for them if they are not responding anymore, for instance. The last focus is contributions related to other open source projects, for instance, Git. And yeah, basically it's improving projects that we depend on and make it better for everyone. So accomplishments. So since October, so yeah, this is a graph that shows the number of community magical that were included in the last, in the few last releases. As you can see, our community is working really hard, maybe harder than us. And no, I'm joking because all these merge requests are getting in GitLab for most parts, thanks to our merge request coaches. As you can see, I started a bit more than one year ago. I was a single merge request coach and then Sean joined as a coach in July and then Jenshin, Kilemon, Kushal, Adam and Tim. And yeah, that's how we get as many merge requests as we can in each releases. Another accomplishment is the issue batch. So we had our first issue batch back in December last year. And the next one is this weekend. So if you want to participate, you are very welcome. It includes triaging issues, closing issues, finding duplicates, adding labels to issues, reproducing bugs, et cetera, et cetera. So I want to say thank you to Mark for this because he's really active on this. Another accomplishment, this time I will say thank you to Robert, he solved the great change log crisis. Maybe you know this one. So yeah, basically we were always asking contributors to rebase their branch because of conflicts in the change log file. So now it's resolved and each merge request includes a separate change log file that is then included in the real change log actually is time. Another accomplishment is about the CE to e-merge. So as you might know, we regularly merge community and T-shirt into enterprise edition. Back until January, we did that weekly. Actually Valerie was doing that weekly and right now we are doing it daily. So it's really helping on having less conflicts and smaller conflicts and also developers can start their branch on top of a branch that is more in sync with the community edition code base. The next step is to optimize this work. Yeah, to address the same issue, we also added a CI job, which is a compact check, basically trying to detect if your branch will conflict with the enterprise edition code base. Then about our test suite, we are trying to reduce the duration and to get it under control. And the first step for that is to monitor it to see what takes a long time to run and what should be improved first. So I want to say thank you to Nick and Alex for setting this monitoring and the tool that we use to use the data. And actually you can click on the second link and it's actually a perfect dashboard so that everyone can contribute, obviously. Yeah, now GitLab QA, so we now have a GitLab Corelty Insurance tool thanks to Gregorz. Basically it's testing GitLab as a whole, including all the parts that make GitLab. For instance, it includes testing workhorse that is not tested in the GitLab Rails test suite. It already cuts some broken behaviors and we will try to integrate it better with GitLab in the next week, seven months. And the last accomplishment I want to speak of today is the GitImporter thanks to Kim who contributed to the GitI project. We have a GitImporter, GitI for the people that don't know it. It's a community managed fork of Gox which is itself a lightweight GitLab basically, right, written in Gox. So with that, I will go with the concerns. Right now the main concerns are about issue-triaging because we have a lot of new issues each day. And I want to remind everyone that issue-triaging is shared responsibility basically. Right now we have Marc who is working full-time on that but anyone can help to address any issues. You can check out the issue-triage policies page if you want to know more. And the second concern is about community merge requests. We have between five to seven new merge requests per day so that's okay but the issue is that we have a quite big backlog of 170, 75 merge requests. You can see the repetition for which team basically most of them are about platform discussion in front of them. And also, yeah, I want to remind the reviewer that we will start to bring reviewers from the team to review community merge requests because they are as valuable as team merge requests. And now for the plans. So yeah, basically it's, most of them are the continuation of our accomplishments so far. So we still want to improve to reduce the test suite duration, improve the community to e-merge situation, integrate GitLab QA better into GitLab, improving the code quality and also improving the reviewer's life by using static analysis so that style improvements are detected, not improvements, the style issues are detected by a static analysis tool rather than by a human. Then we want to streamline the developer's experience so that as a developer you can just run a few comments and you are up and running with, for instance, a million projects in your local instance so that you can experience how it feels to have a lot of data in your GitLab instance. And the last point in this slide is about Git external object database. So this one, it's a project that Christian is focusing on. It's basically to bring GitLab LFS into, sorry, Git LFS into Git and so that it's shipped with Git and everyone can use it as a default tool. And much more, so feel free to check out the rest of the plan. And yeah, that's basically it for today. I will answer your questions if you have and thank you for your attention. Thanks for the presentation, Remy. That was helpful. What percentage of merge requests are from the community versus from ourselves? That's a good question. I don't have the numbers but I guess that's not hard to compute. But I would say, so let's see if we had, so for instance for 9.0 we already have more than 90 community merge requests merged. And I'm trying to see how many we have merged in total. So we have 300 merged in total. So that's almost a chair of the total. That's really not bad. I think. Thanks, that's 30%. That's amazing. Cool, thanks for that. Yeah, so next question. On the change of crisis, we were waiting for work to be resubstantion.vb2. That's a posh merge union. Right, there's no been undetected but we're still waiting for an upstream the regular to burn the regular version that they support. So Robert said there's a lot of pain there. Yeah, exactly. We couldn't know why, so basically. And I think actually I think the solution from Robert is also addressing other points than just the conflicts. For instance, since it's generating the changelog dynamically, it's also generate the changelog for the intermaster branch and also in the stable branch. Yeah, that wasn't the question but thanks for saying that. Test all the things all the time. Yes, exactly. But not too much because otherwise it takes too long. Yeah, so if there are no questions, no other questions, I will say thank you and see you in five weeks.