 All right, welcome everyone to today's edition of the platform backend focus group update. There's one thing I'm going to do a little bit differently this edition and previous edition and that is that I'm going to start off with a little meet the team inspired by Sean, our discussion engineering manager who did the last, who did the same thing in his last iteration. I'm going to start with myself. That's just because I'm doing this in order of joining GitLab. And then we'll have some time to get to the more interesting members of the team. But yeah, let's talk about myself. My name is Dao Amam. I'm the engineering manager for the platform team. I live in Utrecht in Netherlands and I joined GitLab a little bit over three years ago. And relevant to kind of my job in GitLab is the fact that I am a maintainer of the back end of GitLab C and E. One of the many, but that means that I'm one of the people who can merge requests right into the master branch. Everyone in the GitLab team in the GitLab backend team is a reviewer. Everyone is encouraged to review each other's code as much as possible. But there's a slightly more select set of people who can actually merge stuff in. And on top of that, I'm also a maintainer of GitLab Shell, which is also a back end component of the GitLab application. So that's me. And now I'd like to go to the first team member of the team who is Ruben. Ruben, would you like to take a moment to introduce yourself and tell us a little bit about what you do at GitLab and in your personal life? Sure thing. Thanks, Dawid. My name is Ruben Davila. I'm based in Lima, Peru, and I have almost two years and three months in GitLab. So I recall I joined the team when we were like 50 people. Right now, we have grown a lot. We are more than 200, I think. So really happy to be part of this awesome team. Always learning new things every day. So I am a back end developer. Mostly I work on the GitLab PE project. I have also done some work on the GitLab PE project. Also, I am a maintainer of some internal applications like the license app. Also, the customer's app or the subscription portal, which is the place where our customers purchase our subscriptions. Well, there is always work to do in the customer's portal, giving our customers half special requirements sometimes in order to purchase our subscriptions. And also our sales team always needs some help regarding our internal tools or with some issues that customers report to them. So yeah, in my free time, I mostly enjoy going for a walk with my dogs. I have two dogs. It's a nice time where usually the solution to the problems comes to my mind while I'm walking with my dogs. So yeah, that's me. I think James, are you there? Thanks, Ruben. James just messaged me to say that he's not going to be able to join right now. So I'll quickly go over his slide. James Lopez is a senior developer on the platform team. He's based in Acronia in Spain and he joined a little bit over two years ago. He maintains takeoff, which is a tool that we use to deploy to GitLab.com. He's a Merchant Quest coach, which means that he helps our community members get their contributions to GitLab ready to go into GitLab with our requirements for spec coverage, documentation, all of this stuff. He's an expert on the import-export feature, which allows you to transfer a GitLab repository from one GitLab instance to another by exporting it into an archive, which contains the repository itself, the issues, the Merchant Quest, everything else, which can then be imported into another GitLab instance, maintaining the relationship between all of those objects. He's also an expert of the cycle analytics feature and he's an expert on the whole release and deployment process for GitLab.com. He is a release manager right now and he has been for the last couple of months and he has done that job a lot over the two years that we've been at GitLab. It's kind of a rotating function for context. So that's James. Next up is Thiago, who also mentioned that he was not going to be here because, as it says there in the bottom, he's currently snowboarding in Andorra, so I'm sure he's very sad that he wasn't able to join the FGU. He's a junior developer on the team. He also lives in London. He used to live in Portugal, but he moved there about half a year ago, I think, and he is an expert of the repository mirroring feature as well as import-export. Next up is James Edwards Jones. James, would you like to introduce yourself? Yeah, sure. Another developer from London. So we often meet up in London. So Thiago and I worked on Mixacles over the last month on the more GitLab internal side. On GitLab itself, I've recently worked on stuff with LFS, like a variety of issues for that. I've been working on protected tags and I've been working on restrictions for protected branches, so you can control who has the ability to unprotect a branch. And I've been working on group SAML, so that's SAML4GitLab.com on the per group level instead of for the whole instance. So those are the things I tend to get pinged on, but I work on all sorts of things and can never remember what I worked on. But yeah, and in my spare time, like a couple of days a week, I'll go to the gym. So I'll have to be working more in a US time zone. But apart from that, yeah, just general stuff. Thank you, James, Bob. You're up. Yeah, so I'm also a developer on those teams. I live in Belgium and that's quite close to where all of the people in the Netherlands are, so we often meet up there. But I'm definitely up for joining you all in London once as well. I've recently worked a lot on the external authorization feature in the GitLab EE. I think that's a premium feature, so it allows more fine-grained access controls using an external service. I also worked on the forking feature that is in Libre. I also worked a lot on the internationalization stuff together with the ribbon on our keys. But generally, mark lecture is better at remembering what I worked on, so I get a lot of things in. That's about it for me. Thank you, Bob. Francisco, you're up. Hi, everybody. I'm Fram. I'm a senior developer in the backend team. I'm based in Murcia in the southeast of Spain, the sunny part of Spain. And I joined GitLab last October, so roughly seven months. Like when I'm a maintainer of the customer app, but I'm not so experienced as he is, so please ask him first. And lastly, I've been working with some wiki issues and I like to work with it and improve it. And in my spare time, I don't have much, but most of it is for my family. So yes, yes, that's me. All right, thanks some. There's two more people who are not actually part of the platform team, but they are people who are highly involved with everything the platform team works on. And these are our dear product managers, James Ramsey and Jeremy Watson. As you can see here, they both are kind of responsible for half the stuff the platform backend team works on. So they're involved in pretty much every issue in every section or every feature that you'll see covered in the rest of this function group update. So let me get to that. What have we been up to in the last six weeks? I skipped, I switched my FGU with whoever was last week because I couldn't do last week, so it's been six weeks since the last iteration. And since then we have released GitLab 10.6 on March 22nd with a bunch of things contributed by the platform team. And a nice thing is that now you'll actually be able to put a face to those names I have listed here. First of all, CICD for external repos. This was of course covered in depth in that release post. This is something that James, Edward Jones, Ruben as well as Tiago contributed large parts of the backend code too. Then we have a low allow modification of fork merge request branch by project maintainers, which was built by Bob external authorization control, which was a effort that spans two or three releases. And also Bob worked on primarily, we have product import and export APIs and some other import export related improvements that were contributed by James Lopez. And of course we have a lot more that we contributed to 10.6 and for example, bug fixes, performance, this kind of stuff. You can find this if you follow that little link to more. We also finalize development of GitLab 10.7 last Friday. Normally the feature free is the seven, but of course we don't work on weekends. So the feature free is to place on the sixth. And I'm gonna talk a little bit more about what we actually built for 10.7 in one of the next few slides. But next I wanna go to what's gonna happen today. In about 45 minutes, we're gonna kick, well, we've already kicked off development of GitLab 10.8 today, but in about 45 minutes, the public kickoff call will take place where the two product managers I just referred to will have the honor of telling the world about what's gonna go in GitLab 10.8 from a platform perspective. So I could cover it there. Of course I have a pretty good idea of what's gonna go into that release, but I don't wanna steal their thunder. I do wanna talk a little bit about GitLab 10.7 though, which we will release on April 22nd, and which like I mentioned, we finished up just before the weekend. First of all, we hope to get the first iteration of basic group level single sign-on for GitLab to come out using SAML. And like James already mentioned in his introduction, this is something he spent a lot of time working on over the last couple months. And if you wanna know a little bit more about what this entails and what it will be able to do in the first iteration, then I suggest you check out that link. We will also be launching a feature called Project Badges, which Francisco worked on, which will allow you to specify an image URL with some parameters, as well as a web URL with some parameters for badges like the CI status, the code quality, things like this, that will be displayed on the product homepage right by the product description. In the past, this would be added in the readme by a lot of projects, and it's still a good place to edit because it transfers wherever the repository is shipped. Whoever downloads it will have those badges available. But on github.com, this will often turn out to be below the fold of the initial load of a project homepage. So we wanted to bring those a little bit more into view right where the project title and description are located. We are also adding the ability to restrict modification of specific protective branches to admins. James also referred to this a moment ago. And this will allow companies to set up certain protections that will not be able to be overridden on a project level by an individual project owner or group owner because only admins will be able to unrestrict certain branches. For example, if a company has very strict control over what can and cannot go and master it, who needs to sign off on things before it can go into master, they don't want project members to be able to temporarily remove the protection just to sneak something in. There's something that James and I worked on like I mentioned. We are also adding get LFS objects to project exports. And of course, we're also gonna import these. This is related to the project export import feature, which I referred to a few moments ago where you can transfer an entire GitLab project and all of its related data from one GitLab instance to another. Or even you can import it into the same GitLab instance, but then you'll end up with a complete clone of the original project, including all of the issue and work your best data. In the past, we didn't include get LFS objects, which meant that an imported project would technically be corrupt because if you checked it out, you would get all kinds of errors about missing files. But now we are actually downloading all of these Git LFS objects into the archive that you can download when you're exporting. And then when you import that archive, we will make sure that those Git LFS objects are not properly placed, located so that the Git project will be able to use them. And we are also adding an API to export a project and automatically update it to a URL. We've had an API to export a project since 10.6 and we've had the functionality to export a project for a while. But right now, if you export a project, of course, the product will be generated in the background, the export will be generated in the background. And when it's finished, this file will be stored somewhere on GitLab server and you will be sent downloading by email, which works fine if this is a user interface feature used by an individual user of GitLab. But if you wanna automate something around project exports, you don't wanna have to read an IMAP email inbox to find the actual download URL. And even if you could check the API to find the download URL, you would need to pull it continuously, which is, of course, also far from ideal. So from 10.7 and on, you will be able to specify an upload URL, which could be to an S3 bucket or some other location. And the export will automatically be uploaded to that location when it is complete. And of course, 10.7 will have a lot more stuff that we worked on and you can find it in that more link. Then on May 7th, we'll plan to finalize the development of GitLab 10.8 and then on May 8th, we'll start developing GitLab 11. And I'm sure that before then, there will be a big kickoff where the project team will tell everyone what's gonna be in that monumental 11.0 release. So that's the last five weeks, next five weeks, and you all got a chance to get to know the team a little bit better. Any questions at this point? If not, I'm gonna count down from 15, 10, five, and nothing. So that means you all get 15 minutes of free day back. See some of you, I'll see some of you in the team call and everyone else, I'll see you in five weeks when the next platform update is on. Yes, do. Have a nice day, everyone. Bye.