 Hey there everyone. Thanks for joining us and welcome to the GitLab kickoff for 11.9 very excited to be here I'm Jeremy Watson. I'm the product manager for manage and I will share my screen and get started with the agenda Cool. So you should be able to see by screen now. So the first item that I'm once excited to talk about is Group SSO so in 11.8. We're shipping the ability to enforce SSO for groups on GitLab comm and in group and in top-level groups We're iterating on this a little bit further in 11.9 by allowing users to actually dedicate user credentials to these groups So instead of having a shared account for users to utilize when managing Resources in these groups. You'll actually be able to not only enforce SSO for these groups using SAML a SAML based identity provider But you'll also be able to actually force users to use a dedicated user account and email address for this for this For your enterprise use. This means that when these Employees are off-boarded they'll no longer have access to that account and they won't and they will be forced to use that email address to be able to to do their work creating a really nicely a nice isolated environment for them when When they're doing work for your for your group and get lab comm The other thing we're doing is we're introducing the ability to deep provision with SCIM When employees typically are off-boarded The need for large enterprises for using identity providers is to off-board and remove that user from connected applications at the same time You'll be able to do this now in GitLab and create a really nice secure off-boarding experience for employees So if you're curious about this, I encourage you to go to this epic here that you this present in the first link Where you'll be able to not only read more about the our plan for 11.9 We're also our plans for SSO in general or forget lab comm for enterprises in general Moving on from there There's a couple of really exciting features that are coming up 11.9 And then one of them is this restrict forks for private projects One thing that enterprise is typically have a need for is to restrict the visibility of their forks on private projects To ensure that no one accidentally creates a public fork and accidentally exposes code Now you'll actually be able to lock this down for private projects to ensure that those forks stay Stay secure We're also doing we're also changing the all of making a change to our permissions model and allowing developers to modify and remove tags I'm not a predictive branches previously They're really able to remove them and add them and now they'll be able to modify it as well and we're also I'm also excited to announce we're moving a number of features down to core The first one is external authorization, which is the ability to maintain access controls for projects with an external with an external service Allowing developers to create projects and groups and then also the system header and footer message messages feature which allows you to Create and have a system message visible in the header and footer of every page and get lab So really excited to move these down to to core and and a last-seat users to enjoy these these features as well And lastly we're moving forward with their with their user experience and a number a couple of number of areas I'm really excited about the first one is our group overview so currently the group the group page for on the On the overview page and group list looks like this and we want to improve the user experience By not only adding a middle column and also improving this the overall presentation of this page But also eventually adding the ability to pin projects to the to the group overview page so really excited to do this and For this kind of step forward in the user experience And then lastly we're also adding filtering to the project dashboard So you in the future will be able to sort and filter the project list by group project tag and visibility level And also we're iterating on the project settings page from users from user research by Refactoring that page and making it easier to discover settings. So that's all we've got manage Victor over you for plan Thanks, Jeremy. So you should see my screen now. And so in the plan stage, we're doing a couple of really exciting things last iteration we released child epics or sub epics what we're calling them child epics essentially just multiple levels of Epics and what's really interesting is that we've gotten a lot of good feedback on it a lot of customers have been saying that they They've been waiting for this feature for a long time. So we're basically doubling down and improving the feature on a number of fronts Firstly basically just showing the epic relationships in a better visualization So right now you can essentially see epics only one level down But if you look at this particular issue What we want to do is allow you to see The tree view essentially so if you look at this, you know, all the ways, you know epic child epic and Child of that epic and so on and so forth all the way down to the issue We're also planning to put that under a tab because we realize that this May get a little bit cluttered with all this information just right below the description in a particular epic So if you have ideas about that or have any particular feedback do jump into this issue and let us know as part of that effort Viewing that tree structure it within a given epic or within a given issue for that matter It might be very helpful to see your parents and you know You're essentially your ancestors and we already have some of that if you look at this particular issue I see my parent epic and if you look at a given epic such as this one You can always see the parent epic as well But you can't see all your ancestors and that's exactly what this particular issue is about is Seeing those ancestors so you can now only see them and see how far you're down in a given tree But you can quickly navigate to the relevant one maybe like two steps above Creating a child epic from an epic is a different It's not about visualization but making a little bit easier to actually start epics And you don't have to go back to the epic list to to create an epic say you're you're Breaking down work in a particular epic and you want to just create an epic right there or create an issue for that matter Right there. You can do so with this a new design that we've come up with So this type of design already exists in an issue board and many of our users say that they find it helpful And then we want to bring that same concept to an epic as well Well, you can create an epic a child epic from an epic and this related issue You can create an issue from a child from an epic as well And we're gonna work on the child ethics first this particular change is Just something that we wanted to clean up very quickly. We launched a feature to You know filter on your activity feed and issues MRs and even epics And so we're gonna clean up epics in particular first So if you've filtered away a comment, so you're just seeing system notes Some users have let us know. Oh, where did my commenting ability go and it's confusing So it's not user error a lot of folks said, oh, it's my fault. It's user is definitely not user error It's a it's a product needs to be a little bit better and helpful and we've designed exactly that so in this particular case You can see that to add a comment go back to comments only or show all activity Another feature I'm so so that that pretty much wraps up epics For for plan and moving on to another area that we're really excited about is boards So with issue boards, we've made a number of navigation improvements to manage multiple boards And so now you can search multiple All the boards in the board itself and with this particular change you'll even be able to see recent boards So if you navigate and you use maybe like, you know, three four even five boards Regularly and it's probably annoying for you to have to always scroll even search This change will allow you to see those recent boards right away It's actually cashed in the navigation you want as you can click on it right away and see that related merge requests in an issue And so this is something that Where we've are we were actually shipping in 11.8 this new particular design We're shipping that but we're actually adding even more information in this particular issue in 11.9 So we're going to add additional information as you see here But this particular change you actually see in a couple of weeks this additional view So for example, I'm an issue right now You see that how it says one related a merge request this will be in this nice new UI similar to related issues And finally starting a discussion for a non discussion comment basically supporting threaded conversations a little bit better Well, something we started in the previous iteration and we plan to finish it very soon in 11.9 James you're up. Thanks Victor Um We've got quite a lot of exciting things coming in create a few of these exciting things for 11.8 were things that we sorry 11.9 We're things that we planned for 11.8 So I'll move through those quickly, but one of those is require codon or approval and we've introduced codoners I've passed few releases and improved it release after release and Ultimately what we're aiming for in 11.9 is to require approvals based on the codoners rule They'll show up in the new improved merge widget, which gives you a breakdown of all the different approval rules If you're if you've enabled multiple approval rules and give you a sense of penance to approve the change to what files And if the approval rules been met, so it'll be very useful for large projects where You really need to require a certain level of approval in different areas of the code the next change that we've been working on is enhancing suggested Changes to support multiple lines So this is what the interface looks like currently you're able to propose a suggestion In a code block and what we're going to do is make this feature support Changes to multiple lines. So at the moment you can propose that line 45 becomes a different version of line 45 Or maybe two lines instead, but sometimes you want to take multiple lines like three or four lines that maybe form a logic Block or a function and rewrite the whole function So we want to support those sort of smaller changes that span changing n number of lines to m number of lines We're also looking at Continuing work we've done over the last releases to improve the merge request diff interface We want to support the ability to quickly expand the entire file So we added the ability to comment on unchanged lines, but now it's a little difficult to get to those unchanged lines So we'll have a button to show the full file that'll expand the full file in the diff Allowing you to comment on any line that you'd like So moving on to some of the the features that are new for 11.9 Group merge request is something that we've been planning for quite a while it's a It comes about from a challenge where you have multiple projects So GitLab has this we have GitLab CE we have GitLab Workhorse get lab shell giddily Giddily proto and often changes need to be coordinated between those Projects and merged in a certain order and so ultimately group merge request is going to provide a nice overarching interface that allows you to code review all these changes in one place but one specific part of the challenge is coordinating which Merge request should be merged in which order and so we're going to be introducing the ability to order merge request and link them So that you can say that the change to GitLab CE that depends on a change to giddily Can't be merged until that prior Changes merged and this is going to help companies and teams with services architectures and applications that are spread over multiple repositories This should be be very useful and this is coming to GitLab premium. I think the issue is incorrectly labeled And then the next improvement that we're bringing is to allow developers to create protected branches Protected branches a really important control in who should push and change code and often a lot of organizations say no one can push directly to a Release branch or master branch But one thing that prevents is people creating new branches and so Typically these branches are created from branches that are already protected and so what we're going to be doing is making it possible for Developers to create say a new release branch from the master branch assuming both of those equally protected and so basically Anyone can create a protected branch as long as it's from a already protected source and this should streamline The release process and other kinds of protected branch operations that happen in a lot of organizations without actually Creating the opportunity for new code to be introduced, which is really what the protected branches feature is all about and Finally, I'm very excited to Share that we're working towards replacing the single file ace editor with the web ID You've been able to use both editors side by side when editing files and get lab for quite a while But the web ID is a really great way to edit your files and we want to make that the default way to do it so we've been working at Making sure all the capabilities in the single file editor are available in the web ID The last one that we're working on in parallel is moving files so you can rename the path and remove the file And also we're working on single file launch performance. So the web ID will launch really quickly so you edit the file right away and As part of that we're going to be adding a feature flag And starting to roll out the web ID is the default editor for everyone so we're looking forward to everyone's feedback and Making editing on GitLab even better Over to you, Brendan Great, thanks James My name is Brendan O'Leary and I am the product manager for the verify stage of the DevOps lifecycle here at the GitLab, I'm very excited to share with you what my the verify team is working on In 11 9 so I'm just going to share my screen here We also have a little holdover from 11 8 This is the cross project pipeline dashboard again. I won't spend a lot of time on it We talked about it a little bit on the last kickoff, but we're really excited about this feature We've learned a lot in The work that we got done during 11 8 for this and we're really excited to ship this in 11 9 It's going to be a very powerful feature that allows users to Visualize the status of the pipeline across various projects that they care about So it'll be a personalized dashboard that you add the products projects you want to see to and then you can see Not only the status of that projects pipeline, but all of the dependent pipelines Up and downstream from it. So this is gonna be really powerful for folks that want to understand you know where pipelines are across many projects and This also will This will ship in GitLab premium But there are features from our operations monitoring team from the monitoring stage that come in ultimate to this So we're kind of combining efforts between the monitoring team and the verify team to make this a reality Next up we have cross project triggered by so in 11.8 We introduced the concept of a triggered keyword And a bridge job that allows you to trigger a downstream pipeline from an upstream pipeline Which is great You've been able to do that for some time with GitLab But we enabled the way we enabled it was you had to curl The API in order to do it which is fine and works But we wanted to make this kind of a first-class citizen So we did that in 11.8 with the triggered keyword, but even more powerful than that In 11.9 is going to come triggered by So instead of having to know as a parent or upstream project What all of the projects that depend on you are and trigger them from your pipeline? Projects can simply set that they are dependent on an upstream project and then every time that that upstream project Projects pipeline passes on the on the refs you specify your pipeline will automatically be triggered This this makes a lot of sense because then you don't need to Be aware like I said of all the downstream projects that rely on a given library or project And you can easily add a new dependency If you're you know spinning up a new project that that's going to depend on some upstream library So we're really excited for that And lastly, we're adding what we call simple protection of CI secret variables in the logs So again for some time things like the CI job token have been obfuscated within the the GitLab build logs that are printed out for each job in your pipeline But or what we're going to add is the ability to say okay if we have a protected variable Let's let's also obfuscate that from the build log just so we can prevent Accidental leaking of that of that variable and so here we can see Kind of a before and after view on that issue if you want to check it out Where CI job token is obfuscated today, but a protected variable is not and then once we we shipped us an 119 Those protected variables will also be obfuscated in the logs And so that's it for verify and I will pass it on to my friend Jason for release Hey everybody So taking a look at what we're doing on the release team this time. We've got perspective merge pipelines auditing for feature flags and permissions for feature flags so perspective merge pipelines is a Way to keep master or whatever branch you're doing your releases from more stable so what we're going to do is basically take the The content of your branch that you're merging from the content of the branch that you're merging to Combine those into a new ref and then run a pipeline on that perspective merge And only merge it into the target branch if it's green. This will give you a lot of control over making sure that Changes that maybe can merge technically okay, but actually are no longer valid in terms of Performance or functional behavior that those are blocked from going into master and causing downstream pipelines pipeline problems We're also doing some investment in the feature flag feature that we released recently We're adding auditing where all of the events that are associated with managing your feature flags are Are going to be recorded in the already present GitLab audit log And we're adding permission so you can control who is able to make changes to the feature flags that you set up in the last Release we've added environments So this will be an environment oriented permission system And you'll be able to use things like environment specs in order to define what the behavior is for different environments So for example, you can have different permissions on review slash star and that sort of thing And that's it for release. So I will move things over to Daniel. Are you here Daniel? Sorry, I was muted. Can you all see my screen great? Okay So for 11 9 the configure team is going to focus on getting a couple of items from 11 8 over the line The first one of those is moving chat ops to core So we talked about this The last time and you know, we think that this is a feature that is highly usable and customizable by developers and Individual contributors. So we want to bring it to core. So we're going to work to get that over the line in 11 9 The second thing that we're going to work on is the ability to enable and disable auto DevOps at the group level for GitLab.com and This is basically if you have multiple projects and you want to enable or disable for all projects Right now, we would have to go project by project So this will give you the ability to do it for all of your projects in a centralized place and give you more more control Next we're going to focus on updating our Kubernetes deployment label selector So the label selector would currently use on the ployboards queries for pods that match app to the CI environments log and that causes a couple of problems First if the user deploys helm charge that are already set the app label it has to be manually changed and Also, users can experience a collision when they tag deployments with CI environments log So we want to prevent those conflicts when doing our filtering So we will provide a separate mechanism to do so Next we're going to focus on a just-in-time Kubernetes resource creation So the kind of the genesis for this issue is the ability to create clusters at the instance level So our current approach to create clusters at the group level for example creates those resources as soon as you add the cluster So it will create a namespace. It will create a service account for each one of your projects Of course when we do this at your instance level where you may have hundreds or thousands of projects It's not something that scales well So we want what we want to do is we want to create those resources just in time When it's necessary to do so so that way this will scale well And we're going to be able to use it at the instance level and hopefully we will follow up With the ability to create those clusters at the instance level Next we're going to chat about a couple of our serverless issues here from 11.8 we have one that it was showing the invocation count for your functions and This is basically In conjunction with the scale that we're showing you for the function We want to show you the amount of times that those functions have been triggered So we will work to get that over the line in the level 9 Then in serverless as well We want to eliminate the need for the users to have to define a git lab CI.yaml So for functions this git lab CI template shouldn't really change So we want to kind of abstract that from the user so it's simpler to get up and running with functions and that way ultimately what we want to do is Bring the building of those functions over to git lab CI So we can take advantage of all of the features that we already have and we don't have to build all of those Kind of for a Knative build so it'll make it easier to troubleshoot To view logs and to view just activity for your function builds right on the git lab CI and the last one that we're going to focus on for serverless is Usability improvement and right now when you deploy Knative to your cluster You don't really have the ability to change the domain after the fact So what we're going to do is allow users to update that domain after Knative has been deployed And that's it for the configure team Josh over to you Awesome. Thank you so much Daniel I'll go through and talk about what we're planning to do for the monitor team Let me go ahead and share my screen All right So we have four main things we're working on in this release the first one is we want to improve really the ease of use and how easy it is for administrators to They'd be aware of what metrics and how their instance is performing the instance being Josh We may be viewing the wrong screen. We see your YouTube window right now. Okay Okay, thank you for letting me know let me try that again All right, well, we'll go ahead and just try this Apologies there. All right. Hopefully that's coming through. Okay. If not, please let me know Josh, we still see your YouTube video. I'll share my screen and you can talk. That's fine. Yeah, thank you I'm not quite sure what's going on there. I appreciate it. Thank you Victor. So going on with the the audio us packaging of Grafana What I'm trying to do is really make it easier for administrators to really be aware of what's how their instance is performing in the health of Their instance right now we do offer of course Prometheus monitoring of the instance out of the box and then so all those parts are being monitored by Prometheus But if you want to take a look at those you'd have to manually install Grafana and hook it up to Prometheus yourself And then install the dashboard that we provide for Grafana To render those in a nice kind of convenient way And so what we're going to do is we're going to have an automatic way to include Grafana and Configure it for the previous data source and I think the dashboard All within the on this package and when they get easier to consume consume and get started with monitoring of the instance again Right off the installation package itself We're also looking to do some extra things with our alerts that we support from Prometheus so What we're looking to do here is that right now when alert comes in from a previous configured alert We currently send an email out to the users However, what we're trying to do here in this release is we like to then I'll start supporting opening issues based on these alerts So for example if you have a set of high severity alerts or some potentially some incidents What you can do is you can route them to get lab and you can then have issues open automatically based on them And so this can help you to really track and understand what's happening with these With these alerts and front for the basis of like an incident management type feature We're working on and continuing to iterate on here in 2019. So you can then also do things like setting a template and Having that app mentioned certain groups of people so they can be aware of it and also potentially attaching labels To help fit into the workflow and so folks are aware And so this is a really great way to help again start sort of tackling an issue or an incident alert Right with and get lab and tracking the status of that again in an issue itself We're also working to improve the century integration which we're launching in the love that eight release right now We ask that you to configure a URL and that URL has a couple components with this release We're improving that experience and so we can essentially automatically generate much of the URL you give us the host name And then you give us an API key and we can then pull the project list And then you can simply select what project you want to configure And then from there again, you just hit say and that's much easier than trying to compose the API URL yourself And so it's a nice little improvement there to the configuration experience the final one working out here for The modern team at least the major items is you want to add support for multiple queries per chart We actually asked for for this a little while ago But we actually lost support when we added Sort of we went to the convert into the database model of storing all of our metrics and our in our chart definitions And so we're going to go ahead and extend the database model to support this again And that benefit here is that you can now define charts That have multiple queries within them. So for example if you wanted to have Both the P99 and the P95 Time series on the same chart You can now do so if those require a different query to generate each time series And so this essentially just allows you to have a little more flexibility around how you can build charts and Define the queries that power this different time series within them So some great features there for the monitor team this release and I'll pass it on to Fabio to talk about what's great coming on the secure team Thank you Josh, and I'm very happy because the team is growing in people And so we are even more ambitious than usual so we can See in my screen, which are the issues that want to work on in 11.9 Let's start with the first one So we want to create a sastralizer to detect secrets and repositories So sometimes developers just push their AWS credentials or their passwords in the rare pose Part test will be able to spot these credentials and to warn the users so they can remove them They can invalidate them. They can revoke them and they can mitigate the problem This will be automatically part of the sastral results as a first iteration. We are considering moving it In a first-class position in the future So please go and the issue and put feedback on this. I'm very happy to hear what I think about that The second one is about auto remediation So we already started the process and now you are able to download a patch With the changes that you need to to make to your code to fix Vulnerabilities automatically with this further step There will be a button in the details for the for the vulnerability That will allow you to create a merge request directly from this screen We already committed the changes that you need to apply in order to solve the solution So you don't need to download the patch and to apply it manually to your repo anymore You can do it automatically from the gilab ui So the next step is that This process will create a pipeline because there is a new merge request and the pipeline will verify If the changes are solving problems and at the same time they are not introducing failures in your testing Integration tasks unit tasks. So that's a very good improvement for auto remediation story We also want to show container scanning results in the group security dashboard So this is part of the iteration to bring all the security results in the group security dashboard In the previous release We just added container scanning results to the database and now we can show them Consistently along with the SAS and dependency scanning results in the same dashboard So users can filter it or they can just see them in a single list We feel that people don't need to care which is the source of the problem They need to care which is the most important one to address first We also want to arrange container scanning reports because at the moment there are a few details You can get from the from the report of the issue That are saying which is the problem how to solve it Details about that this information is partly available from the tools from the Information that we can collect so we want to show them to users in a good way So they will not be overwhelmed by new information, but they can get benefit from it Let's talk also about some SAS improvements So these improvements are about the SAS analyzers that are part of the SAS offering So the tools that we run in order to get the vulnerability information for your code The first one is about multimodal Maven project support Most of the time Maven has a multimodal approach So there is not just a single application in the repo There are multiple models or applications at the same time The current implementation is not able to completely cover all the information that are in the repo In this iteration we will cover it and so even if you're using multimodal Maven projects You can leverage our SAS information You don't need to update any configuration You just need to update your system and the new tool we run According to the new module and will detect multimodal Maven projects The second point about SAS is TypeScript support TypeScript is a language that is quite common nowadays even if not as Java for example But still useful, we want to implement an analyzer for it So if you have a TypeScript project in your repo It will be automatically detected and analyzed for security vulnerabilities Without any change out of the box if you're already are using SAS The last point is about the vendor templates for security products At the moment we have a problem because every time we want to update Definition of the job for a security feature For example, SAS or dependency scanning Users have to manually update their job definition Just copy and pasting our template from our documentation And so it may create some problem in keeping people up-to-date with the latest version In the previous release of KeyLab we released includes With the ability to include a local file So we want to provide a local file for each of the security features that we are providing So SAS, dependency scanning, container scanning and so on So people that want to be always up-to-date with the new definitions Can just include this vendor file as part of their job definition The Gila Yammel file And as soon as they upgrade to the new Gila version They will benefit from the new syntax from the new Potential of our tools without changing it in each and every project all the time So this will scale very well for large organizations And that's all for Secure in 11.9 Back to you Josh for distribution Thank you Fabio, that is super exciting Let me try and share another one more time here Hopefully this will work All right, is that going through okay? If not, please let me know I can try something else Not sure it is Looks great It's going great That's great, fantastic You're looking good though Cool So on the distribution side, we have three main things we're working on here in this release The first one is that we want to refresh the official AWS marketplace listing for GitLab's AMI We do have one up on there today It's unfortunately old And so we want to go through and we want to be able to refresh that and keep it And more easily keep it up to date And so we are working on that in this release It is an internal ticket there just so you know a total issue It does have some of our kind of important details in there But we're working to again make sure we can keep them up to date And have that more of a good offering for our users As right now we do currently post automatically new community AMIs in the community marketplace But those can be hard to differentiate versus sort of everyone else's GitLab AMIs That they also publish in the community in my area And so this is a great way to hopefully have a more official and easier to find Get that marketplace listing We're also working to add EKS or the Amazon managed Kubernetes offering To our GitLab chart test suite So we have a great set of automated tests that we run Currently they run on only one Kubernetes flavor, GKE And we want to make sure we can expand this out to EKS And so we can make sure that any changes we're making to the charts Or to the underlying container images do not negatively impact folks who are using EKS And so we're trying to now go ahead and expand out the test beds that we're utilizing Again to make sure we have a wider set of tests As we do have a number of users for example who are using EKS And so we should make sure that we don't break anything accidentally since we're not testing it The next thing we're working on is continue to improvements to our operator Our operator within our Helm chart is essentially an application code that Sort of manages a few things for us in the GitLab installation within Kubernetes Primarily what it's doing right now is it is managing the upgrade process So with GitLab to achieve zero downtime upgrades across a fleet of various instances and services The required sort of dance if you will or choreograph is a little too complex for How to manage by itself and so we've actually built that logic into the operator And so it can manage what parts of our application upgrade when to run migrations when to run post Migrations and it can do that all by itself. And so you have a very easy Zero downtime upgrade utilizing the GitLab Helm charts on Kubernetes And so that's a really exciting thing we're working towards enabling by default here Very soon And so that's what we're the major things we're working on in distribution and I can pass over to Jeremy to talk a bit more about fulfillment Thanks a lot josh This is the first update from the fulfillment team So this is a new team that we've started at GitLab with a focus on licensing billing And telemetry to make sure that we can move a little bit faster in those areas So the first item that we're shipping at 11.9 here is uh is solving a problem That's long been an issue on gitlab.com. Just the lack of the ability to buy add-on minutes for ci runners Right at the moment. These are hard limits for all plans But now we're going to solve this limit on nine by allowing users at every tier to purchase add-on packs of ci runner minutes So that the hard limits are no longer a thing You'll be able to use our shared runners as much as you'd like That's all for fulfillment for now. James over to you for giddily to take it home Thanks, sir searching for the unmute button. Um, we've got two really exciting improvements on the giddily team I don't have any screenshots to show you because giddily doesn't have a user interface But it is what makes git work really well at gitlab um, the first improvement we're working on is objective duplication For public projects when you fork them. We've been working on this for a while I think I updated a few releases ago when we were working on an early version of this It's now running for a few projects on gitlab.com, but we're hoping to get it into general availability um in 11.9 So that you can use it yourself. Um, the last hurdles we're working through with support for georeplication And once this featureships, it means that forks will just use a much smaller amount of disk space So if you've got a large project by gitlab or some other popular open source project when you fork it, um It will it'll only use a very small amount of space Only the the changes between your project and the upstream project will actually be stored Separately on disk and so this is particularly helpful for customers that host their own gitlab instance rather than using gitlab.com managing their storage costs And the second improvement is a performance improvement that i'm really excited about it's part of working on objective duplications We worked with github to upstream their work on delta islands to the git project And we found performance improvements by using delta islands To repack pack files as part of garbage collection In git and that should make clones and other git operations faster when fetching data from the server And so we're hoping to ship that performance improvement as well in 11.9 to make it even faster when you use gitlab And that's all from the giddily team. And I think that's the last From all the different categories we've got here at gitlab for 11.9. It's going to be a massive release There are so many amazing features i'm struggling even to remember the first ones but um Look out for the release post when it comes out There'll be all the details even more screenshots and you can follow along in the issues And as always leave feedback and help us Build the best possible version of gitlab. Thanks for your time