 Welcome everyone, this is the Sieg-Release, Kubernetes Sieg-Release maintainer's track talk. My name is Carlos Panato. In my right side here is we have Kat and Joseph, and in my left side, if I can do the hands correctly, it's helpful. We're going to introduce the Sieg-Release itself, the team. It's composed by two teams, like two sub-teams. One is the release team, that's our fancy and everybody loves it, and nice. And the other one is the release engineer, that's like we're under the ground. Like no one wants to work with us, but I think you should join us. I'm gonna pass the next slides to Kat. Hello, I like this mic better. So the release team changes a lot over time and we're getting better at it every cycle. Every cycle something goes wrong and we fix it in the next one. So previously, until this current release, version 130, the release team was made up of six sub-teams, but when we moved all of our internal planning and project management to GitHub project boards, it reduced the workload for the bug triage team so severely that they had almost nothing to do. So we decided to merge them with the CI signal team into the new release signal team. Which is going pretty well. It's a little bit stressful because that is a team that is busy like the entire cycle. They always have something to do, but it is better than having one team doing nothing for the whole release. So we consider ourselves to be doing a good job when we manage to automate a team out of existence. This is the second time we've done it, I think. So we're pretty proud of that one. This team is also changing the way we handle documentation. So documentation is not optional. If your KEP has user-facing changes, those changes have to be documented. It is a hard requirement. And we're gonna be pretty inflexible on that one. To make this more clear, we have introduced a docs freeze. Previously, the last deadline for documentation in a release cycle was called the PRs Ready to Merge deadline, and people treated this deadline as though it was very soft. It's always kind of a struggle to get to documentation in and reviewed on time, which is real stressful for both the release docs team and SIG docs who have to review that documentation. So to make it clear that this is a requirement, we've moved the docs deadline more in line with our enhancements deadlines. So like enhancements freeze and code freeze, this is a real hard deadline, and if you're gonna miss it, you have to file an exception request. You have to tell me how much more time you need. You have to justify it. We have to talk about how risky it is, and we'll approve or deny that request. So this is active in 130. We'll see how it goes, because the docs freeze deadline is next week. I'm moderately anxious, but it'll be fine. And this is also the announcement for our release theme for version 130. This is version 130, ooh, ooh, Bernadies. I made a joke on Twitter like three years ago that if I was ever allowed to lead a release, I was gonna name it ooh, ooh, Bernadies. And I didn't think that it would actually happen, but it did, and I don't want it ever said that I can't commit to the bit. So that's me committing to the bit. That's my cat, Espresso. She will be 22 this year. Thank you. I'm going to pass it off to Joseph. Thank you so much. And yeah, so I want to just briefly kind of give them just a little bit more of an overview. I think we got a good introduction about Sig Release, and there's also Release Engineering. And just, you know, I'm from a product background. Primarily though, before that I was an engineer. So I wasn't on this dark side very long, but the one thing that is really in common is that having a roadmap and really trying to understand the problems that you're trying to solve is gonna give you direction. The theme of the talk is about planning for maturity. And think about, a lot of us have been in this community for a long time, 10 years for some of us, and we're now getting into our teen years. And so it's important for us now to kind of evolve, to kind of grow. And that's really what's been happening in Sig Release. So real hard work, kudos to Laurie Apple, to Marco here who also worked a lot as Sasha who's not here with us, and many other members of the community in Sig Contrabex for helping us really to define what this roadmap is gonna look like for us in 2024 and beyond. And really the focus is that we wanna really provide really a robust framework that's fast and flexible, release pipeline for Kubernetes. And the reason why we want these things to be like that is because there's a lot of projects that we feel are important that's gonna help the broader Kubernetes community, not just for the release that this team works on and cuts, but that we can support them so that as we evolve and as we grow, it'll help this platform become even more resilient, it'll help releases come out with less friction, and ideally it'll be more secure. And so I have a link in there, take a look at the roadmap, because there is some interesting things in there. Some of the deliverables, things that are currently in progress that are contained in there that kind of highlight opportunities for you to be able to possibly get involved with Sig Release or Release Engineering. And I think as Kat mentioned earlier, she talked about the release team, it's kind of the real introduction really to the Sig Release is what I would say. And if you really want to take advantage of it, coming into these meetings where these action items are being discussed where we're trying to make artifact validation more robust, we're also kind of working on recently on the package building and that's been a long-term project. But if you want to really dig in and find out how I can get involved, how can I really get up to speed? Because that's something I sometimes find as difficult is where's my entry point? How do I know I can help here? Do I have the skills? So I would highly encourage you to take a look at this hard work that's been put into it. And there's other ways you can get involved. Just recently Marco had and Lori, they worked on a survey along with many others where we need your input. So if you really want to help us, to take the survey, it's going to be open until the end of April 30th. This is going to help us, especially define our roadmap, some of the deliverables that we have. The other thing I was going to mention is, sometimes on the release team, and I thought, crap, she's been on this tenured for a very long time. I did before that for about five, six releases. But one thing you know, and especially as we're downsizing the team, because we're really automating it so that we don't need as many members, you may not get accepted to that team. So what I encourage is there's a blog post that was made by an individual who actually had that same situation, and he really showed how he found a way into the release team, got an internship, and made great impact. So I highly encourage that. We're right there on Slack, jump in, you can follow the channels, conversations, and then we hold meetings every Tuesday. So we have one that is like EU, Asia-Pac friendly, as well as one for the West Coast. So really look forward to seeing you join us there. I'm going to now hand off, because we're going to get a little bit more into some of the projects that are actively in motion. I'm going to give this to Carlos. Thank you. I'm going to maybe switch mics. Don't want to shake it all in the mic. Okay, now we're going to talk a little bit about the release engineer, and we always try to seek the Holy Grail, but maybe we're going to see. One of the things we've been working the past cycle is, for me, is one of the big achievements that we had in the past year, is that we are now also, now building the package in the community side, or not anymore like depend on Google, to build the package and publish those. And one of the things we've been working, like Exclusion and Marko, which is here, like dedicate a lot of time to move this forward. We decided to use the open build service from OpenSuzi, and Susie, thanks for Susie to provide and host everything for the platform for us that we can do the success. It's hosted on paykgs.kates.io, and you can scan this QR code that goes to a blog post that explain in detail how you can migrate on this. But quickly, you just add the key ring for the new one to your Kubernetes.list and then download the GPG keys for the download stuff. Notice that here, we are pointing to the 1.8, 28 release, you just replace this to the release you are interested to use. Next one is like the things that the release team was working is some release actions for the GitHub actions workflows that is reusable. We like put out that you guys can use in your own side projects, on your own projects in the GitHub that uses GitHub actions. We have actions that automate the provenance, the S-bombs, the check the padduses and stuff that we all use this internal inside the Kubernetes ecosystem, but we are also like providing these two bother projects outside the Kubernetes itself. Like it's easy to use is I think is well documented, but we can talk this later. And I want to call action here is like most of the people doesn't know like what the release engineer like take care. Those are a few projects that we run and maintain. And I'd like to like have someone from here or from the community to help us to maintain those projects here. The key code here is scans for the list from GitHub that all the projects we have. And we have like from release SDK that contains, for example, GitHub wrappers or Git stuff to do Git operations easily. The release is more like as the name says, it is like a side functions that help us. There's the tele-holded for the provenance data, bone for the build of materials, the release action itself, the OBS CLI to interact with the OBS service that we just showed before. That project needs, we have like a lot of stuff to do here. And we have site guys, promo tools. We have a bunch of things here that I would like to, if you want to work in one of these projects, you are really well welcome to do this. Please join us to maintain those projects. Oh wow. Okay, I'm gonna pass this to... Yeah, you find out unexpected? So this is my vision for the future, a fantastic fantasy land of things that we would like to release and maintain. So part of the work that we've been doing over the past 10 or two, three years has been taking all the code that we've been building and trying to make it reusable for their projects. Like Carlos showed how we've been splitting some of that code into other projects. And we've held some initiatives together with CNCF to also start spreading those tools, particularly in the security space to other projects under the Kubernetes umbrella. So we held the CloudNet Security Slam in December where we had a bunch of students and volunteers that jumped in to help build security features into other projects on Kubernetes and like in grenades and genetics and gateway API and others. And that went really well. But there's, we currently have a little bit of a problem. So we're building fantastic things for Kubernetes and also some of our other releases. Like we have ESPOM, so which is great. We also have provenance, which is fantastic. And we have signing in most of the artifacts in Kubernetes and it's fantastic. But if you're generating all of that with the data but no one is consuming it, then what's the point? So that points to maybe a shortcoming in our tools which is we've become, I don't know, very good at generating some of that metadata but we're also lacking practices and tooling to better consume those information, that information. So when we put all of that work to generate ESPOM's provenance and all that and no one answers that, no one is using it, well, makes Carlos here very angry. And so he will not be having that. So what do we do? We propose to start dog fooding all of that information. So if you saw all of those repositories that we have, what we would like to do is start using that information internally so that we can secure our internal releases and then so that we can provide you with better ways of consuming that information because everything that we do internally, we try to make it also available externally to other projects and anybody who wants to do that. So how do we do that? As I said, first dog fooding, but then how do you make sure that you're finding everything that you need? Well, we are working on a new project to redesign the security feed for Kubernetes. And for those of you who may not be aware of what the security feed is, let me give you a super brief introduction. I have a quote here from a scholar about what it is. So it's an ongoing stream of data describing how vulnerabilities affect piece of software. So this is the process. We'll work a little bit the same way that we currently Kubernetes as a security feed, but we're working together with security to redesign the tooling and the formats. So the way it works is you have a security researcher that starts poking around Kubernetes and maybe finds some vulnerability and that person will report that to the project and the security response committee who is this fan fellows here, they do a great job triaging those reports. Well, in the new version, what they'll do is they will take that report, triage it, and if they find that it's valid, they will assess the severity of the vulnerability. And now they will create, using a new CLI that we're developing, they will create a document in the OSV schema, open source vulnerability schema, which is a project under the open SLEF. And based on that information, they can assign a CVE number. Kubernetes is a CVE number in authority, so we have the capability of generating our own CVEs. And using that information, we can feed it to the old classic vulnerability feed that we have in JSON today, but we also start building a new feed based on OSV. So the format is much a lot more flexible and I won't go into the details because we have very little time, but the idea here is once we have this feed, we can start doing fantastic things. So the first one and obvious one is we will port the release process that we have today to read from that new feed and then start generating things like, for example, the release notes, where currently we have a custom format in YAML that we exchange, but the idea is to have one single feed that ties everything together. Then the next one is what can generate VEX documents, which is information and how those vulnerabilities affect or don't affect the project because we already have the triage that the SRC generates so we can turn that into VEX. And then finally we can modernize our S-bombs and find, I won't go into the details about what S-bombs is, but I'm happy to talk about it like endlessly. So the idea is it's a document that contains all of our components. So we will not have the capability to tie together the components that make up Kubernetes with vulnerabilities that we publish in the OSB feed. But the real benefit here is that once we start publishing those new enhanced S-bombs, things like our own applications will be able to look at the S-bombs and tie them back to the feed so they can do better decisions whether they want to, for example, ingest a dependency or wait for a release or whatever. So those applications will be able to, by using the S-bombs, tie it together to the vulnerability feed and the VEX information that we will publish. I know it's a lot, but I try to do it step by step. And yeah, so to make that happen, we need you. The release engineering team, we love building stuff like it's kind of, I think it's the passion of everybody working there, but there's also lots of maintenance work that we do. Most of the time that we devote today is managing dependencies, updating the base images, Go versions, things like that. So we can always use some help. So if you're interested in some of those areas that we just showed up, feel free to chime in on Slack. We're also looking for enthusiastic folks, no technical level required. And also, you wanna talk about the release team? Sure, I can talk about the release team. So the 131 release team, the application for shadows is not open yet, but it will be open soon-ish. The 130 release is currently scheduled to come out April 17th. So sometime within like two or three weeks of that date, you can keep an eye out in the SIG release channel and the SIG release mailing lists for updates on the 131 release and the shadow application and any changes we might make for 131, but please do apply. Any closing thoughts? Other than just if you have any questions, like we have our contact information. I like I said, I think when they talked about just entry point, like I'm probably that example of you'd probably call me a SIG release stand. But the one thing I learned is that it's a very helpful group. So I highly encourage you to come on board. We'd love to have you. Thank you. Any questions? All right, go for you. Well, very simple question, but very difficult answer, I guess. You have many repositories there. What's the most urgent repositories that you wanted to have help on? On the project, on the projects I didn't get. The most of all of the repos we listed, which ones the most urgently need to have. So the one that needs the most urgent, that has the most urgent needs, is PromoTools, which is, PromoTools is the image promoter for Kubernetes. That project, the code race is fairly complicated is, I don't know if you can see that in the mouse, this one PromoTools. So that's the image promoter. So all of the projects in Kubernetes release their images to staging repositories and then that tool takes them and carries it over to the production registries. That code has a large tech depth and has some docs in it. And so any help refactoring that one, it's a steep learning curve, so for warning, but it's one. Yeah, we are about to start planning and create a roadmap for that because in the past months, we've been adding more registries that we are thinking, like we are thinking now in AWS and other regions on GCP. And that promote this tool is doing all those stuff as well. Like we need to think a little bit better how to improve and be faster. Because in the past, like sometimes when we do the release, I think was 128 or 129, the release process was taking more than four hours and that's not good. Like we need to speed up on this part, but for that we need to refactor everything. Yeah, it was designed for a world where we have three registries, now we're close to 30, I think. So real quick, all of the repos that we have here are important. They all exist for a reason. So I think dependent on your skill set, like show up, we'll figure out what you can do, what you want to do and we'll point you in the right direction. But all of those repos exist because they're serving a need. If you are a front-end developer, we have the download Kubernetes, one that is mainly UI. Yeah, and there's also the release node sites. I don't think it's listed here, but that one is in some front-end in, I don't know, in JavaScript and none of us know how to handle it. Yeah, we need help there. Yeah, we need help. You are using a web developer. Yeah, you're using chat tpt to help us out. Yeah. Any other questions? Thank you. Enjoy your lunch.