 Welcome everybody at their retrospective where we look back on what went well and what went wrong and what we can improve based on the last release 8.16 And Shana is the first point, but I'll just read it out. This, the notes of this and this specific recording will be public and the kickoff as well. So did you know that? So let's get started with what went well. This release like I couldn't believe I was a little bit pessimistic about what we would be able to get done because while there was Christmas and then other holidays and then we went to Mexico with the majority of us and we still were able to do the whole ID to production being a cool computer engine and it's just amazing and it was done during the summit. So that was really impressive. Besides that we also shipped a lot of other cool things so it can't believe it was again the best release ever. Victor, what else went well? Hey, so for the issue linked in the schedule, we are moving toward a new navigation for the project settings. Right now it's a cog to the right. And so that went very well. This release because we're able to chop it up into multiple releases. Each issue could be released individually and we didn't know what could be released all at once. So in the previous iteration we actually tried to do it all at once and was not successful but for this one we were able to chop it up. And so UX and engineering and product all sat together at the outset to have a plan and then toward the end of the release, Jose had and team had already finished three of the five things. But the third issue was not merged in so he didn't have to rush and say let's merge this in quickly because the first two were already merged in. So I think this is a great example of just chopping it into individual pieces and we don't have to rush for that last, that third particular one because it wasn't necessary for the first two to be successful. So fingers crossed we'll get the rest of the remaining three in and actually that third one should be in like this week and then the remaining two should be in for 817. So I'm excited about that. Jacob. Yes, thank you. So the what went well this release the front end planned quite well and we were able to get even with the other stuff going on, we were able to get like 98% of the things finished. Camille. We shipped the first iteration of the API improvements. It actually shows really deep sense. So it seems like a very good direction to follow. I don't really see who is next song. Is next. Same story. Yeah, so basically, we forgot to send either the milestone to a dot 16 or the speaking stable level for 18 mediquits, which was quite a lot. That means that I have to go and ask people to say, hey, does that mean that these two go in 8.617 or 8.716 or and, you know, sometimes it could be 17 or 16. I don't know. So you have to go away. So it's very difficult to guess. So yeah, we should definitely get better at that. Next one is for some mind. We also sort of know the great compact check thing, which is there, which fails in the list of bills. And because we can, you know, we can merge anyway, we can ignore it and then merge with warnings, then we forgot to, we forget to create a anima for the version of the tapes or whatever. So the point with that is that when we think in this table, then we have to do the marriage to ourselves and it could be something that, you know, we, we don't know very well or like myself, you know, ended up fixing some CSS stuff or things like that, which is a behalf for me to get some times because, you know, you know, the differences in me and you have to check double check and that takes a long time. So we, we get better at that and that would be great. And we obviously have the now some improvements already in that we have, we have daily C2E marriages and stuff like that. But still, even though I got quite a few conflicts already and I, I do remind people anyway on in the major quest. So yeah, we should make the fail. Yeah, we should. I think there's an issue with that compact check. Remy may know more, but sometimes he may actually fail and because the, the clone is too shallow or something like that. But yeah, next is Camille C testing. Okay. Okay. I don't know about you, but for me, the testing in the last week was really painful. We hit a lot of 500 euros, we hit a lot of unbalanced test suits. We hit a lot of a lot of master being correct and then actually all future magical being read. I saw that there is a mention from Stan about infrastructure issue. But this is definitely something that we should focus probably in this release on improving that for everyone. So your items next. I cannot hear you at least. Sorry, I have a headphone issues. I hope you can hear me now. Because we couldn't deploy a release candidate to get lab.com for a long time. We didn't notice that project size limits were broken by a community edition. So we had that merge request that was merged just after the 815 merge window. And the whole reason we merged it just after the 815 merge window was so that we could catch this kind of issue in advance. Drew says we also deployed on summit travel day and in the data support requests. Yep, I really regret that. But the alternative to deploying on summit travel day was to wait a day longer and we'd already waited like at least a week. Right, James, and we really didn't want to wait any longer than we already had. The reason we couldn't deploy, I think James has more insight into this than me, but we just had a migration that was not slow. It wasn't a performance issue. It was just a correctness issue on staging and on lab.com. So we spent a lot of time fixing it in CE, waiting for that build to pass. Merging to E, waiting for that build to pass, cutting an extra release candidate, waiting for the package, deploying the package, finding out that we needed to make another change. And then starting again, which is quite a frustrating process to go through. Next up is Jacob S. Thank you. So the great merge when build succeeds crisis of 2017 was mainly due to an understanding of how turbo links affects JavaScript and what gets loaded where and the tests that were in place to catch that the merge when build succeeds was failing, didn't actually catch it. Even though the tests were there, they just, they didn't catch it. And also no one else who was reviewing it. We caught it so it went out. And so then we wound up fixing that a little late in the game. We did get it fixed before the end thing went out, but it did wind up in there, which was bad. Also, because things went in very late in a couple of instances, there was no times for anybody to see it for no eyes to be on things. So some people wound up squashing bugs on a Saturday on the day before the release, which is one not cool for the weekend, but also not cool because it's so close to it and that's, you know, danger zone. What can we improve James L. Yeah, so I created a separate issue similar to the one Maureen created for the a dot 15 release. Just with a list of observations. Some of them already mentioned like the chicken to stable or milestone or being set. But also like deploying to station takes a long time. And has some issues with the with applying itself. There's a separate issue as well for that one that link there in the end. Especially for RC three release coming three, we had a quarter few issues with the deploying. I need to go on time, basically to deploy. But the other things that I mentioned there. Like I said, as well, you know, last minute, my request, some of them were quite crucial anyway, because there were big bugs like this. And maybe we'll be sexy, sexy and stuff like that because we were actually creating more boxes of that. Since people were merging with our knowing that the build has paid that goes especially young. On the release day, I think, well, definitely Saturday, both E and C master was or failing, basically, so that gets broken. And yeah, just pretty to how I look, let's go a few things there. I'm not going to end up hate all of them now. Yeah. Next is Victor walking lots creatures. So, so good lab is getting bigger, we have already done a lot of the low hanging fruit features from a product perspective. So we're making big bets where I have a lot more people on the team now. And so we're starting to create a lot more features that may take more than a milestone. So maybe we haven't been optimized or our structure and our processes have not been optimized to achieve those things. So that ticket just links to a couple of solutions that a lot of us already know and have been chatting about, but do take a look. And truly, it is a cross functional problem to be solved. It's not just engineering a product, but everybody from UX to marketing sales. How do we minimize the risk of working on a feature for maybe two or three months before it's in front of a customer. How can we solve that risk as we tackle these bigger features and problems. Dimitri. Yeah, sense. So what we've seen quite often is that even if RC one is on time, then people start merging stuff and we have delays with RC two RC three and bugs that appears in the late stages of the release. And then people basically do overtime merge stuff like in last minute. And yeah, we have basically a less stable release as a result. So one of the proposals that I will mention kick off to would be actually once we create RC one, not merge master into a stable branch at all. So at this point, basically since RC one will only fix bugs for the ongoing release process and it will ensure that there is no migration appears during RC two RC three in the stable branch that will block deployments that will create new regressions and so on. Yeah, Pablo. Yeah, this is something that we have been discussing for a long time. But never actually do anything about it. So we're talking about finding a way to deploy branches on staging by using containers. It's going to take a while. It's not going to be for the next release probably it's a goal for q one. But basically what I want to do is I want to lower the bar for development to actually get a big data sample and to deploy somewhere else that is not your machine. Right. Still, if we have problems merging into easy et cetera, et cetera, that's not going to be immediate solution, but at least it's going to be a way of getting feedback sooner and faster. So that's it. To the kick off now. Yay to the kick off. There's a link on the bottom. We haven't taken it already. The kick off document. You're going to get three more seconds. All right, so eight at 17 next best release ever. I hope you're all ready for it. First of cool things eight at 17 will be the last eight release. So that means that March 22nd will actually release get lab nine. Finally, guess how many months ago it was. I went to the blog post of eight at all. And I look like what did we actually do. And actually it wasn't eight at all that we integrated CI. It feels like an eight ago. What was 16 months ago, but it's still pretty amazing to think how far we've come since that very first eight release now having, you know, see I being a very major part of kid lap. Maybe the main differentiator at this point. And we shipped metamost better one at the time. So by now we're all very used to shipping metamost and and at the time and this is for some of the backend developers that still remember we actually we had satellite so we had every repository had like a satellite repository where we did operations and it basically meant that every repository took twice the size of the repository on the disk. And we removed it in this release. So it's a really nice release. I think it's really nice to look back. It's also nice to see that nowadays we actually ship so much so much so many more things than we used to do like the blog post was quite short or something. So what we'll be doing and what is important is release for one making enterprise edition. Better right we want to build great software for everyone, but we're also business so we want to make sure that enterprise edition is a very attractive option for everyone and in particular our customers. Of course we want to bring ID to production and now with monitoring to the world. So we have all this cool power and finally people can actually use it you can start the trial on Google cloud and you can use it all yourself and we want to make that better so with every single release we want to make it better. Of course we want to make it fast and always more awesome. I think those two are obvious but especially the fast part is something that we're investing more and more in. Those are the important things and then I want to add a little note on scheduling and how we are always doing it. So we are making some changes to make it more asynchronous. So previously we had a scheduling meeting where we come together and discuss the scheduling. And I just want to make clear that this should all happen asynchronous and we'll do our best going forward to all do this all neatly asynchronously and have like the next milestone already scheduled by the 19th which is the date that I picked like this so it might still change but And the same goes for this meeting right so the kick of meeting all this information that is here should not you should never have to look at the agenda here it's just for you to get out of here what we're all working on. But it should always be clear to you what is important for you and your team so if that's not the case then bring it up and and lastly on that note what how do we make asynchronous the single source of truth for every single milestone for every single release is always the issues. So we have a particular milestone and single source of truth is the issues. So you never have to look at this document you don't have to feel bad if you haven't seen this document this is just to tell you like this is all the cool stuff we're working on for me to have another moment in a month where I can get all excited about everything. So with that said, now tell me what is next what are we going to do. Alright so the first thing we're going to do for 817 actually is not going to be released in 817, which is that way on purpose, we are going to be preparing for 9.0 with every major release we can make some breaking changes to the API and things like that. And if we don't do them in 9.0 would you would have to wait for 10.0 so to make sure that we get those API breaking changes in on time. Donal's Waldo already gonna be working on those API breaking changes during this release month. So the link points to a whole list of stuff that we want to change and that we want to release with 9.0. That's the first thing which no one's actually gonna see in 817 but we don't want to wait with that stuff. Then for stuff we are going to see. Yeah. In order to make so API changes people have to upgrade GitLab but they're headed the things that are talking to the GitLab API. They don't can't upgrade it at the same time as 9.0. So I think that any changes we make should have should just be deprecations of features that were added in 8.17. So ship in 17. So the thing that's going to happen is that pretty much all of these things were actually going to change. We're already marked as deprecated during the 8.x life. In 8.17 blog posts we're going to announce the stuff that has been deprecated up till now and it's actually going to change forever in 9.0. And the parties that know hey we use one of these endpoints to change. They will have time before they upgrade to 9.0 to change their own tools to adopt those changes. Can they run 8.17, upgrade their tools and then run 9.0? Are all the changes that we introduced in 9.0 already in 8.17? I think no because there are some things that were changing in a backward incompatible way. So they would need to update their tools and GitLab 9.0 at the same time. Are we very sure that those things are not backwards compatible? I haven't looked for every single issue. We can definitely do that. What are you suggesting exactly that we would make those changes? So 9.0 should only be deprecations or things that were added in 8.17? I think we should discuss this further than an issue because there has been a road to 9.0 issue for a while where we came to a different conclusion, but we can talk more. The kickoff is four times. So then I would like to give the mic to Mike who will tell us about stuff that's actually going to ship in 8.17 for platform. One of the things that we're doing is we're grouping some of the EE and broader changes together. So I might actually hand over to Regan first to go through some of the first few changes. Did you just hear that? Yes, I am. Alright, so basically we are going to create an auditor user. So what is an auditor? It's going to be the user that will have the same admin privileges such as look at all the issues, look at all the MR and stuff like that in an account, in an instance. But they won't be actual admin. So this is for enterprises that need these kind of audit privileges. We'll try to, well, I'm not exactly sure what that means to get elastic search in shape, but I assume it's about making it work more reliably. We will also continue the work on disaster recovery. So this is a long project that we've been working on for several months now and we'll continue that and hopefully ship something in 8.17 for that. About the small features improvements, do you want to take over my core? Yeah, absolutely. So with the changes that we've got going in for 9.0 and some of the sort of things that overhang 8.16, we don't have a huge amount of bandwidth in platform team for improvements. But we do have certainly two changes that we're committed to. The first one is for one of our larger customers, I believe it's IBM, and just allowing them to have impersonation tokens so that they can use the API effectively through, not through a walk-in through impersonation tokens, and then also allowing people to adjust the way that the GitLab syncs to remote service and making that configurable. And then finally, there's a stretch goal, which doesn't appear to be a huge amount of work that will be creating GitLab with Microsoft Teams, which is starting to gain popularity and is one of our most popular features, feature requests that we have from our user base. And that will allow people running Microsoft Teams to get webhook support, that activity coming from GitLab will go into Microsoft Teams. And it's over to Victor. All right, so Regis, I'll let you jump in. Sorry, I can't, but I'm coming forward with issue boards. That's exciting. It's been stagnant for a couple of iterations now. So right now, users can just drag issues into the quote unquote board when they're looking at the board itself. So we have this backlog list concept, but it's a little bit hard to use because you might have the bazillion issues and you have to keep scrolling, or you might need to search and so forth. So we're going to improve that UI a little bit and make it match the workflow use cases that we're aiming for for issue boards and then see how our customers react to that. And the other big change is that some customers has been asking for saving filters or saving the milestone in particular. We think this reflects the fact that issue boards are used per milestone or a team might call it a sprint or an iteration so it doesn't make sense that you see a board and it's not already filtered on that milestone. So right now we're aiming to ship that as part of EE because with CE you just get one board and you can only change the name of the board. So with EE you can have multiple boards and also actually save the milestone with it. So let Regis talk about the other ones as well. Thank you Victor. So for the discussion part we are doing, we are adding an export issues in the issue list. This is going to be for EE. So basically the ability to export a given set of lists based on the filters that you have selected and let you actually put that on Excel and do some additional planning with it. This is a very highly requested features that we are going to ship. We are also adding a new feature called license finders. So most projects actually uses external dependencies, you know, like open source dependencies, stuff like that. But sometimes those dependencies change their license and if you are a commercial project and you are using an open source license and then this project would change their license to copyright to copy left. Basically it's going to be a legal nightmare if something happens in the future. So we are going to add a feature that will help you detect which gem or what which external dependencies like gem, for instance, change their license. And we will warn you when you want to merge that merge quest that contains the dependencies that have changed their licenses. I think this is going to be very valuable for most companies. And Mark and Camille now to talk about the CI changes. So let me jump in. Sorry really quickly. We are working on squash or more accurately Sean is working on auto squash. So obviously customers are asking for competitors have it squashing multiple commits into one commit when you merge the merge request. Sorry, Mark and Camille. Yeah. So, the big focus of the CIC team was going to be deploy boards, given the new shift in the cycle of RC one cut off. There's a pretty much near zero chance of that actually merging in seven days. So I scratched it off just to let it be the milk is previously we said we're going to work on that. Instead, we're going to be focusing on the rest of the stuff on this list. There's a pipelines trigger API that we just need to do so we can deprecate the build triggers API in 8.17 so we can kill it in 9.0. Another improvement that's been sort of long standing is this mini pipeline graph that shows up on merge requests so that we can kill the builds tab in 9.0. And then some chat ops improvements and messages, and then a few other back end things long polling and person volume for the community stuff. Camille can jump them anything else if anybody needs anything but Josh Prometheus. Thanks Mark. So what we're going to do here for 8.17 is add monitoring to the idea to production workflow. And so what we're going to do in this release is add the ability to collect and display metrics on the environments page. And so you'll be able to take a look at your environments for communities based other boys. And be able to see CPU memory utilization directly within GitLab, providing a single workflow to deploy and look at what's going on across your environments. So that's very exciting and looking forward to doing that. We're also going to be adding a few additional exporters in the Anodes package so you'll be able to collect additional information on the health of the GitLab server for the self hosted installations out there in GitLab CE. And so that's also something we're continuing to include in 8.17. And Jacob, on to you. Thanks. So for the, we're adding in Webpack, which is already pretty much done, but we're going to put it in early so that we can see anything that would happen with that which is going to help out the front end a lot. And we're going to just see how that goes. There is two other issues that just there's obviously a lot of other things that we're doing. We're helping out the back end also, but from a front end perspective, we want to make the large commits usable. And we're going to also remove jQuery UI. And we are also currently auditing turbo links, but that's not on for this release. That's just something we're doing for this. DZ. Yeah, so between drone, the release process, how it's going right now. So we create RC1 from master branch. And we basically deployed. And then after a few days, we merge master branch into the stable branch again, and create RC2 or RC3. And interesting thing is that basically all your aggressions, all the problems that you faced during RC1, they don't benefit you well when you again merge master into the stable branch. So you get new regression, you get new migration, new problems and so on. And as a result, we don't even strictly say what you can cherry pick into the stable branch. So people get whole features cherry picked one day before release. And as a result, for example, a release manager is just burning himself trying to fix migration because he cannot deploy, for example, RC7 to the GitLab.com or whatsoever. And basically, RC, the release candidate, makes no sense because it's not a release candidate, it's just a random snapshot of the master branch, which brings us no value of detecting regression and fixing bugs and so on. So the change to the release process post means a merge request is actually saying that you should not merge master into the stable branch. So RC1 created from master and it creates a stable branch and then stable branch goes its own way and you can merge into the master whatever you want during the whole development time, yeah, every day. But we will cherry pick into the stable branch on the regressions and security fixes. This way, regressions collected during one or two weeks of user testing is actually usable because we can fix those and we don't have new regressions appearing. The second problem we solve is that we don't have issues on late stage of release process when somehow the new migration right before two days before release appears that cannot be run on the production, which we experienced in last release and release before and so on and so on. And particular I want our release candidate to become actually release candidate, which is from Wikipedia is a state of the source code when new features are not added. And that's his proposal in the merge request and I'm going to apply it until like some huge amount of people put wet on it and the discussion will be in the merge request so please put all your comments there. And once we come to the conclusion I will merge and announce it in the team agenda. Yeah, as a result of this change, we'll get a better quality of release software. We won't get unexpected delays in later release candidates. 8.17 will be shorter because of this transition period, but 9.0 will be longer anyway of the development cycle and yeah, again because of the transition period which will give us enough time to put some of the stuff in 9.0. Yeah, thanks very much for the long intro. Marin, the build part. Thanks Dimitri. So if you take a look at the meta issue that I linked, we missed our mark for 8.16. A lot of things are working progress still and are nearly to be completed, but not quite there yet. So 8.16 release issue was created with that in mind. I think we should be able to get everything that's on this release in this meta issue. There are a couple of things worth noting, ongoing HA efforts for the omnibus packages, Postgres, namely, Ian is on that one and we are also receiving feedback on the Postgres upgrade issues and we are fixing them as we have them. I have to say that we didn't have that many, which does not mean we don't have any left to fix. We are also focusing more and more on all container related issues and cloud images and a couple of ongoing issues with fixing the whole release process. We are getting to a point where we are going to have package promotion finally done. I got reassurance this is going to happen this week. And we are working still towards decreasing the package build time, which is a major pain point for everyone in the team, and also the package size, which is actually not being helped by us adding more stuff in, but it's part of our roadmap. And there are a couple of issues that are still to be assigned. Docker image vulnerabilities can needs to be addressed. We did most important things, but we now can address some of the things that are lower on the priority list. Jagush started working on making GitLab QA more usable for everyone. And one of the first tasks of the build team is actually to help out Jagush to get a move on on this. And like previously mentioned, we are going to add more Prometheus metrics. So that's part of the effort with Prometheus team. And this week, hopefully we will also get a webpack for the front end team or with them result. And one final issue to be decided, this is still being discussed whether we are going to officially have CEOS Enterprise links packages. This is a bit of a back and forth between various teams and external partners. That's about it. Yob, do you want to close the kickoff? Well, you could have done it, Mario, but I'm happy to. All right, let's make this the best release ever and get ready for night at all. Good luck, everyone. Good luck. Thank you. Bye.