 Do we have anybody that wants to do a lightning talk? Oh, Willie wants a lightning talk. Hey, Joseph, this is Mike Snitzer. I would like to do a lightning talk to kind of bookend the earlier conversation about LTS and Red Hat and what we do with Colonel and stuff. It was right at the end of that session, and we didn't get a response into James's question of Red Hat and what we do. Yeah, go ahead, Mike. I mean, I don't need to do that right now if Willie wants to go first. Good either way. No, you're a good man. Go ahead. All right. So James asked the question, you know, SUSE and other corporations, like they've kind of gravitated towards LTS and making use of that for the basis, for their kernels, for long-term support. And so Red Hat just, I'm an upstream maintainer for Device Mapper, right? And so my contribution to LTS is in terms of tagging commits in upstream Device Mapper as the changes go in that should be for stable. And I do that religiously. And then that triggers a cascade of Greg Crow Hartman and others on the Linux stable project to CC in response when the thing gets backported. And the number of failures and rejects and that cause patches to get dropped and the nurturing that goes on just as an upstream maintainer, that's all I can handle to be quite honest. There's a lot of work involved in supporting that and making sure that a patch isn't skipped and that kind of thing. So I don't question that there is a significant effort that is required of those contributing to LTS, but Red Hat just isn't tied to LTS. So the way we contribute is by way of people like myself contributing in terms of upstream maintainer. I don't know, I mean, that's not a great answer, but we don't tether our product released to LTS like the other distros do. So I just wanted to offer that as an explanation for what Red Hat is actually doing as it relates to kernels. OK, thank you for sharing. Sure, we rebase each subsystem individually basically. Each subsystem is able to kind of have its own autonomy. So like device mapper does its own thing, block core does its own thing, XFS does its own thing. And so no one release that actually we test against. So that's a good point. And I've been talking to Susan engineers and I mistakenly said that Susan followed those LTS and it was wrong. And they corrected me. But what we talked about is that if Susan or Red Hat would not, I understand that they don't want to follow LTS because you don't want to stream of fixes from all the subsystems. And I understand that completely. But let's take example XFS. I was talking about XFS and Susan engineers. They do not have a lot of XFS and resources. So they do not want to follow LTS. But if they would have chosen a kernel to be based on, that is the same as LTS or close, doesn't matter. They can work together in collaboration with the community developers working on XFS for LTS and just test together collaboratively, choose the patches, test together, and apply the XFS LTS patches onto your kernel. And it can be LVM or any other subsystem that RHEL keeps relatively updated. So here's the question for you. Are the LTSS patches marked with fixes? Does it matter? They are in LTS. No, no, no. That wasn't my question. My question was, are the LTSS patches marked as fixes? Not always. So and then the next question would be, why not? Because the fact that they are in LTS means that they are fixes. No, a lot of them are marked as fixes. That's how they got into stable. We're not wandering down this road. I'm fixing to go home. Next, Willie, you're up. This one's more organizational than a thing. So for those who aren't aware, Plumbers is going to be in, I would say, October in Virginia. That was November. November in Richmond, Virginia. For the last two years at Plumbers, we've had an MM track. Blusherville and I co-run it in Ireland. We are not planning on submitting one this year. Two reasons. I mean, originally, we've only done it for two years. We started doing it initially because COVID, so we didn't have LSF MM. So there's really no other way for the MM people to get together and have the kinds of discussions we've had this week. We decided to continue it in Dublin, even though we had previously met in California, because it being in Europe meant that we were able to, that some people were able to get to Dublin who couldn't get it to California. So it seemed worth doing last year. I don't see there being a particularly large number of people who can make it to Virginia in November who couldn't make it here this week. I mean, I'm sure there's some, but it doesn't seem compelling to either myself or Vastimal to submit a proposal for a session. And so we're not planning on doing it. If anyone thinks we're making a horrible mistake, now's a really good time to shout at me. Everyone's looking bored. Okay, great. Or they should actually volunteer to organize the mini-con, right? It doesn't have to be you all. No, no, it doesn't have to be me at all. But if nobody knows that the people from last year aren't going to bother doing it this year, then it kind of falls on the floor because they don't know that they were supposed to step up, which is actually what happened the previous year. None of us knew that nobody else was doing it, so we didn't get one. There is no self-interest in my comment at all because I'm not in any way associated with the planning committee of Plumbers at all. But I would prefer if we had one. No, it's fine, obviously, if there is no reason for you to do one. But just speaking for the committee, I think we'd be delighted to have you and Mike as the organizer of the micro-conference track this year. So, bully him into doing one. Thanks, that was it. Perfect. Does anybody else have a lightning talk that I want to get through? Cool. We're going to have a wrap-up now. So, we're going to have the track leaders come up and give a quick summary of what was discussed, plans, how everything went, that sort of stuff. So, let me get Amir, Nikola, if you're around here, or Dan, and Martin, or Daniel, whichever one of y'all, and Mike, other Martin, both Martins. Yeah, so I would just say that quite a lot of discussions, very useful. It seems that we have landed into a new age where we are actually removing code than much more than adding new code. A lot of technical debt that we have to pay. We have discussed to hopefully not have documentation discussion next year again, without too much work behind. And yeah, hard to summarize all of them, but I do rely on Jonathan to have a very good and decent coverage. Just remember what we were discussing and yeah, very productive. Thanks to everybody. It was really cool. Yeah, my personal feeling is that it was very successful. That we were able to make progress on several things. We had a, one thing we had is a meetup of several Fuse developers discussing a few emerging Fuse technologies and how they all emerge together. In the VFS, we had all participate and contribute and having Leonard here as the user space representative really helped some of those discussions going because we were not talking to ourselves we were actually having a dialogue with user space and that was, I'm not saying it's something generic, it was specific sessions that question answered, okay, this is how we're going to do it. Specifically like a K thread freezer. We have this idea, the kernel should notify the user, no, no, it doesn't work like that. No, everything's much simpler and it happened even more than once. We discussed also in the session for VFS a use case, a use case of containers, mounting images. It's a complex thing involving several subsystems and having everyone together in the room, understanding all the moving pieces, having Ted and Jarek go on record saying that if you FSCK an image, it's okay to mount it, they're going to regret this, but things like that. Apart from that, a few sessions like on IOMAP conversion showing that we had some progress, a lot of people, I went around here, asked all the people that led sessions what you take away and basically I got a lot of underlying that we know how to make progress and this is the resolution of many sessions that we had so that's more than we can ask. In the hour track we had a couple of, well three really, really productive days I find. We had some really old friends that we brought back to life, I hope, copy, offload and hinting and a lot of things we've been talking about for a decade that I think we're a little bit closer at actually finally resolving. And new interesting topics, yesterday was mostly dedicated to NMME, we've been pretty much throughout the whole storage stack the last few days, post-COZE and NMME and block and I think it's been super, super productive. On a BPF chart we had about 38 topics so there was a lot of topics we went through. So I think the first one is we got an official BPF end firm, great talk, highly encouraged, you guys go to look at it again. We also have a lot of discussion on K-Fung, how BPF can write a data structure map in BPF alone and new hash algorithm. Another important one is the GCC support in BPF. I heard that was, it went pretty well and I talked to someone else in compiler guide there was a lot of hallway discussion that got a lot of things resolved it, I think that was good. So we also talked about BPF, new way of passing BPF capability, citing the BPF program. So second day we talked about BPF, how BPF extend to other subsystem, I think one of them, one of the highlight is the field's BPF. There was a lot of very engaged discussion, that was exciting. And also we have BPF running as a scheduler. We had, we talked about the progress and what concerns people have in the community. So going back to the networking, where BPF has a lot of use case already, so we still keep finding new use case and new extension there. So one of them is about T6, so it's a new way to attach TC program. So a big discussion there is about having a more meaningful way to define the ordering on attach multiple BPF program at TC. So another good one is XDP. So I think XDP is a BPF extension to the network driver. So it was introduced, I think six years ago, we still find new use case now to further extend it. So it was pretty interesting. So on the last day, I think we have a good discussion on BPF-CI. So BPF-CI is a continuous testing infrastructure. So that's an important part of the BPF ecosystem. It helped maintain a lot on maintaining the code base and fastly changing code base. So we talked about the progress we made there, so we support new CPU architecture. And I think most of the people got a chance to give it a try to try how to test things in the CI. Yeah, I think that's pretty much it. And I see a lot of old faces and also I see some new faces. So hope to see all of you next year. Awesome, thanks guys. All right, so that's a wrap. Thanks everybody. This year we tried something a little bit different. We added, as you might notice, we added about 60 to 70 more people than we normally have. The goal of this was to allow for us to have more new people and kind of like integrate more younger faces, new faces into the community and kind of let them join us here. I personally think it went really well. I don't feel like, one of the things that we always talked about before was like we wanted to keep it really small because we wanted it to be intimate and we wanted to make sure that we were still making progress and that it didn't get too big or unwieldy. Which is valid and I agree with wholeheartedly, but it kind of got to the point where it was just like the same people showing up. And especially as we added more, adding BPF, like it kind of constrained everybody else. I'm of the opinion this worked really well. I haven't heard any negative comments. If you have negative comments, keep it to yourself. No, let me know. If we want to go bigger, we could probably, I think this is a good sweet spot. I know William said 200 people before, but at some, I don't know, but I could be convinced either way. The nice thing is I don't have to be convinced because I'm not doing this again. We have to pick the program chair for next year. Usually we rotate this around the different groups, so File System did it, MM did it at last. I don't think BPF has done it at all, so I think BPF is on the chopping block. So do you guys want to right now throw a victim or do you want to discuss it amongst yourselves and get back to me? All right, discuss amongst yourselves and get back to me. For next year, Tricia has said that we have the option of co-locating with OSSCon again. I know for them that makes it easier because then they don't have to like, when we go separately, it's nice. We all love like being by ourselves, but it means that those, they have to go to the hotel, all the different hotels, they have to get quotes, they have to do all this thing. And so when we co-locate it, it just makes their life easier. Again, I'm of the opinion this worked really well because we have been separate from everybody else. It's not like we've had to deal with anything. And of course, the venue was beautiful. Next year OSSCon is in Seattle, so again, if that does not appeal, then again, I'm open. Again, I don't get to make a decision, but if you would rather not be co-located or you have strong feelings, please let me or the next PC know. And yeah, it is super expensive. I think so. It's going to similar time of the year. So early May. Yeah, does anybody have any feedback or anything they want to yell at me right now? I think it would be really nice if we can get side rooms where we can probably sit down or something. It was pretty hard to have side conversations where you needed to whip up a laptop or something like that. That's all. Oh, and it'd be nice to be able to get beer too. That's sorry. All right, thanks everybody for coming. This has been really great. Thanks to the whole program committee. Like I honestly just deal with logistics. I didn't do the schedule or anything like you guys all did that. So thanks to y'all and thanks for everybody for coming. Appreciate it. Hey, Joseph.