 Hi everyone, it's 4pm in an unusually snowy Edinburgh. This is the discussion backend team update for the last five weeks. I'm Sean McGiven and I'm the engineering manager for that team. This is a cool thing. In epics, you can now reorder issues. These work related to issues, but also issue boards in the sense that you can order the issues in an epic in whatever order you choose, probably priority. That's a nice feature that was shipped in GitLab 10.4. So thanks Yaka and Clement for working on that. The next slide was going to show a speed improvement on the dashboard. So we have basically figured out how to make the dashboard work when filtering by label. The problem is that we fixed the first problem and by making it query faster and removing another one that was completely useless, like the result was literally used nowhere. But then when we fixed that we found that we had another one that is almost useless but not quite. So it takes a little bit more effort to get rid of that. I think hopefully by the time we release 10.4.0, we will have this fixed. So yeah, thanks Felipe for working on that. It's very nearly there. It's just not quite. Similarly with search. Search is kind of a problem in general. So when I talk about search here I'm talking about global search so using the search box in the top right of the GitLab interface. We have elastic search available as an enterprise edition feature but we can use it on gitlab.com at the moment and it's quite a lot of engineering work to unblock that. In the meantime we need to make sure that the existing search works okay but it struggles because it's searching everything you can see. But on a large instance like gitlab.com everything you see includes hundreds of thousands of issues because there are lots of public projects with public issues like the gitlab community edition project for instance and everybody can see those issues. So we don't get to filter out a lot of the search results and it's problematic for query performance. We did improve the query performance here but only for certain inputs like it depends how many results are in your result set. So what we're doing now is limiting that to I think it was either a thousand or ten thousand. So if you have more than ten thousand issues we will just so that there are ten thousand plus issues in the results. We don't expect people are actually searching and paging through ten thousand results. In fact we know they aren't because it times out into the work. So Jan's been doing a great job on this. The issues linked in the title of this slide and you can see there's a whole bunch of attempted query improvements and query plans that we've run through initiating on trying to fix this again hopefully in the final 10.4 release this will be addressed. So both of these issues are like regionals like this close piece this close so we're almost done. The thing that's been challenging has been moving uploads to object storage. We wanted to get this done in 10.4. It's not going to be in 10.4, it's going to be 10.5. It's been challenging for a few reasons. The week before the freeze we thought we had 80% done and we've probably had over 80% left in terms of effort if not in terms of code changes. Michael has written up a great description of the schema of the way upload paths work. So sorry when I talk about uploads here I'm talking about like user avatars, group avatars, project avatars. Whenever you drag a file or paste a screenshot into a comment or an issue or a mode request that's an upload. So we're trying to enable those to be moved to object storage and it turns out that a lot of the code elsewhere assumes that it knows what part of that path is but not the rest of it and assumes that it can just ask a part of it when really it should ask for all of it. We also discovered while working on this that is not strictly related but we use these directories for temporary uploads in Workhorse I think that we have both temp upload and temp upload. I can't remember which is which but one is used for CI artifacts and one is used for LFS files and it's super confusing that we have both and there's that arbitrary difference between them. Basically what happened here was when we started working on this issue we just didn't realize how much this touched and how much complexity there was. We probably should have reached out to a couple of people who we know had expertise in certain areas of how these uploads were used. When we were scoping it out to get a better estimate sooner. So Mika has been doing a really great job on this. I think it's finally ready for review today and everything's passing so we're going to go forward from there. We've got some API improvements. We have APIs now for group issue boards, EPICs and EPIC issues going forward for portfolio management which involves EPICs and roadmaps and so on. We will try and keep the public API parity with every feature so that we don't have to think about this again. It's something we should do for every feature but sometimes we're not so great about it with portfolio management. We really want to make sure that that's there from the start for every feature. We have our OKRs which I'm not going to go through in too much detail. They're on the OKR page. The significant things are just as a high level we're looking to make sure that community contributions are under control. We want to make sure our bug backlog is under control. We want to make sure that important issues from different teams. We currently have different priority labels for security support and availability from the infrastructure team. All the essential issues from those are resolved. In future I think we will try and move to a single set of priority labels so we don't have this like three different lengths for three different teams as priorities. The other thing is we want to move to Rails 5. We're going to pick up work again on that in the 10.6 development cycle and we will see where we get. It is probable that we will need to adapt the existing MR to make it so that we can run the app in Rails 4 mode or in Rails 5 mode and then merge that and then work towards Rails 5 compatibility incrementally. We're also hiring. I think Eric's had this in a previous update. Basically the plan is to double the team size by hiring six developers over the course of 2018. I think hopefully we have one starting in the next couple of weeks so that's pretty stark to the ear. If you don't work at GitLab please tell your friends anyway but if you do work at GitLab and you qualify for a referral bonus you can get a referral bonus by referring someone who's hired so please do that. What's next on the agenda? Jan is going to be working more on portfolio management and Jaco will be responsible for reviewing that. You can see the features there. As you have mentioned in his update yesterday we're going to start working on batch commenting in MRs in this release but we are aiming to ship it in 10.6 because there are some front end blockers there at the moment. So shipping it in 10.5 isn't really realistic. Dif collapsing is something that's been a problem for a while. We have a bunch of different limits, hard limits, soft limits for both blob sizes and diff sizes and they feed into each other in weird ways and difficulties kind of confusing to explain to people but it's also kind of confusing to make better. This is something that I've been talking about with Victor who's the product manager for discussion and we've talked about it quite a lot. We haven't really come up with a great solution yet but we are talking about it and trying to think of a way to make this better. Sorry that was nine minutes so it's a bit long. I'm just going to stop sharing and see if there are any questions. Bob, you were so close with the LFS and attachments thing. Yeah, it's hard to know that. It doesn't look like there are any other questions. I'll give everybody 15 seconds probably otherwise. Remy's excited about batch commenting in MRs. Yeah, so am I. So I just do this manually at the moment so I just click a bunch of lines, start drafting a bunch of comments and then when I'm sort of done reading the diff, I go back up and click comment on all of them. So it would be nice to have that native in the application. Cool. Well, have a great day everybody and I'll see you on the team call.