 When we get things started by just doing kind of a roundtable here, we've got, I assume we're going to have people come in and out, and we can just do kind of a quick introduction for those who don't know who we are. And then take questions from that, unless anyone has, I don't know, like an agenda or something. I don't think we really have that. We have an agenda. Is that a thing? I don't think so. Yeah. Like, I don't actually know what we're supposed to do. Yeah, so, okay. All right, so if you've been to a flock or even a flood come back, there was always a session where you would get to talk to FESCO members and it was just sort of an open Q&A, but also an opportunity to meet them in person. This is the best we can do in these times since it's a virtual event, I guess. So yeah, that's given the time zones and constraints of everything. This is five of us who are here. Like I said a minute ago, I'm David Cantrell, D Cantrell, very original Nick on IRC. I've been working in Fedora for as long as I've been at Red Hat, so I joined in 2005 by being a Linux user and developer since the mid 90s. Many changes throughout history, many distributions have come on, many technologies have come on, and now I'm here, elected to FESCO and hopefully doing some good. So I will pass it over to Neil. All right then. So my name is Neil Gampa. I am actually kind of new to this whole FESCO thing. But I have been around the block for a while. I've been involved in Fedora for a little over 12, since 2007, I can't do math in my head right now, but I've been around since 2007 as a contributor. I've actually been a user of Fedora since it started as a project, even before that with Red Hat Linux and stuff like that. I've bounced around using Ubuntu, Gen2, and a few other distributions here and there. And these days, I'm involved in Fedora and Maja Opens and so on for FESCO stuff. I guess today I would be known as the one who has caused the most trouble this cycle, both good and bad, hopefully mostly good, but from some people's perspective, probably all bad. So, you know, the thing I do is just I try to bring a little bit of the world of Linux perspective and also try to help bring my expertise and a lot of the plumbing layer stuff to FESCO as well as a lot of the packaging and things like that. So I'll just kind of throw my virtual baton to Fabio. Okay, can anybody hear me? I'm not sure this microphone works. It works. Great. All right, I'm Fabio and my nickname is Decathorpe everywhere. And not sure anybody ever got that pun. But all right. I'm mostly involved with packaging on Fedora and I've joined FESCO the cycle before this one. So my term is going to be up soon, I think. And I'm mostly involved with some with maintaining the Pantheon desktop environment and a lot of Java packages. So, yeah. And I think I've been packaging stuff for Fedora since 2015 or something like that. I made you do get into it with Pantheon. It is my fault and I'm okay with this. Yeah, it's okay. It's not so bad. I mean Pantheon desktop was probably better than the Java stack. Yeah, it's definitely less trouble except when the GNOME guys are not helpful. Yeah, well, yeah. Well, I think that's it for me. Who should I pass the baton to? Well, you could throw it up to Kevin or throw it to the right to Clement. Okay, Kevin, your turn. Okay, I hope everyone can hear me. My mic is being flaky and low, but I'll try and shout. I'm Kevin Finzi, Narek on IRC. I've been involved in Fedora since 2005, I think it was when I started taking over the IRC or the XFC packages from Fedora Extras. So long, long time ago I've been on Fesco for ages. I try and, you know, keep the historical perspective around and help folks where I can and yeah. I've been really, really, really, really busy with the data center move lately and things have been flaky and infrastructure. So I've been trying to calm that down, but hopefully we'll get to a nice place here very soon and we can actually start getting more stuff done. So that's my hope. So I will pass the baton up to Clement. Catching it. Thanks everyone. So I'm Tremo Verna, Siviana on IRC. I've been involved in Fedora for four years, maybe almost five years, I think, end of this year. And I've been mostly involved in the Fedora infrastructure, so I've been on the CPE team. And recently I'm going to help a little bit more on the Fedora Corvallis side of things also. And this is my first time in Fesco, so I've been elected just for this cycle. So I'm very new here. Yeah, and I have like my son, Timo T, so he's taking part of the team also. Okay, I've been watching the questions in the chat here and let's see the first one that when we started doing the round table was they wanted Neil to explain your IRC NICS and how many you have and why you have so many. Oh, you're muted. It started with me having only one IRC NIC, I had Conan, which is the name I typically use everywhere. And I used to do this from a machine that I had rented from a friend that ran Fedora server on it and I had IRC running on it and I would just be in there for all the time. In 2015 that server finally died, like the hard drive just straight up failed and it was not recoverable. And so I lost everything for that. At the same time, I moved from where I used to live in Mississippi to Connecticut, and then I lost access to a stable computer. And so consequently, I was always juggling around different devices but I needed some kind of way to persistently keep track of conversations. But I didn't have a stable internet connection anywhere so I couldn't run a bouncer. So what wound up happening was that at work I wound up having a computer that was always running and I had a connection in there and that was set up with a with an account that's Farrow attempt. And then on my laptop for a while I use Sun Goku on my IRC client there. And that was my MacBook. And then my phone use Sir Gallantmon for a while. And then Kingi Nyasha is my desktop here. And then over and then I switched to matrix a little while ago so I retired using Sun Goku so much and I went to eighth doctor which is my matrix client. And actually, now you kind of get this this is like all these different points to interact with IRC is because I IRC doesn't let me have one persistent thing that I can rotate the same identity across computers. However, I've been generally happy with matrix. And if I decide to go into setting up my own matrix home server. I would probably reconsolidate everything again and go back to just using Conan Cuda everywhere. But that's sort of the story why I have so many nicks. Also, yeah, and in some cases I wind up having an alternate Nick because some networks, literally don't let me use my preferred one. Like in, for example, in for a long time in OFTC Farrow attempt was actually reserved by somebody else. And a couple of other networks had some of my other preferred nicks registered already so I wound up having used different names there. But yeah so that that's kind of the story behind is like for a year and a half I lived as a nomad it didn't have a persistent connection and didn't have money to have a persistent somewhere. So I wound up having to have multiple connections into IRC, so that I could have, you know, the, at least the perception of being always available in some form or fashion. And it's sort of stuck. I'm hoping that eventually, as things get a little bit better I still have to do like very expensive housework that and once that's all done, maybe finally start fixing this and going back to having one Nick again because like matrix has actually worked out pretty well. It has a lot of the advantages of having a bouncer, while also giving me an actually decent experience across, across jumping clients, because the one of the disadvantages I found with having a bouncer when I used to do that was going to different computers to actually manually fetch the logs rather than it just being there for me to see so I can keep track of my communications so we'll see how that goes. Maybe I won't be known as the guy with six plus nicks eventually. We'll see. But that that's the story behind it and that's, you know, and I think I have a list of them, my, my list of them exists on ironically my launchpad account, but once fastest replaced with the new account system. They will also be there because they've added the ability to store multiple nicks into fast so now that they will all work. So yeah, that's the story. All right, yeah, that is, that is definitely quite the IRC history. Let's see. As you were explaining that mostly it's people commenting on on your IRC nicks. I'm looking back to anyone see any questions. Do we have any questions. It seems like one's just placing bets on which Nick I will actually that whether or not I'll wind up with multiple nicks even with matrix. I think the current situation but we'll see. I'd like to actually consolidate that because having multiple nicks and having multiple locations has some really huge pitfalls. Like I don't have, I cannot maintain a coherent state of what I'm talking to. It's, it's pretty hard to keep track of everything. And this pandemic has made it worse. Some of my workstation in the office is just randomly going off and on because of power outages and stuff like that and so that's not fun. So, I would definitely like to fix this at some point. And yes, I'm on team having a fedora project make tricks home server I would definitely love for us to have one because that would be that it would just be very cool I think it's it's going to wind up being the future of of communications at least in the open source realm, if not everywhere Okay, here we go. What are some of the projects or goals fesco has for fedora moving forward past fedora 33 in front or other projects. Well, okay, I guess we can all probably say something about this. We all know that the number of change proposals approved right now has hit a record. And they're not all insignificant changes these are, these are quite involved changes that are going in. Some have far reaching impact, probably, you know, every user in some capacity and then others are for specific interest groups but I think that what we're going to see is a lot of attention that we have to revisit a lot of these to work out more of the details for implementation and integration into fedora and that's that's kind of what we do. So, I, you know, having done this for for quite a long time and it's sort of the, the up and down cycle of, you know, introduce new new features and then go through a period of stabilization and sort of almost like reflection on okay what are we doing how do we want to, you know, tweak it and tune it and stuff like that. So I think that that probably is what we need to focus on after this. After these changes go in, hopefully we can hopefully we'll have resources focused on that but it's also hard to say we may see a brand new technology show up that we really want to integrate into fedora and that you know kind of stretches to that again. I don't know. But I guess my thing is I would like to see us focus on stability of what we're integrating now what we've decided that we're doing now for f 33 and beyond. Anyone want to add to that. Sure, I can I can add a little bit to this because I think as the one who is the two, I think arguably most disruptive changes to for this cycle. That is definitely out well has more probably more quote unquote disruptive is the editor change which is not that significant but whatever. But like the two actually significant changes. I think what we're looking at here is like, I looked back over the past five years of the door releases. And I think what what winds up happening is that I think we're starting to hit this cadence where every five years end up having this huge boost of like really big dramatic, you know, things that we want to do and then we refine those over the course of the next five years releases like fedora 21 was the beginning of fedora next and or fedora next or whatever you want to call it. We did the focusing the additions and all that stuff and that was 62 changes by the way, that was that that was the high mark until fedora 33 and over the course of releases from fedora 21 to now, while we haven't necessarily had so many changes, a lot of them have built on that innovation that happened in 21. And what I see what we're doing right now is we're laying the foundations to iteratively develop and improve and stabilize and and make these technologies mature for the next five years, or the next 10 years, the next 15 years, like a lot of people see us with the perspective of fedora brings those features first, and bring that innovation to the to the wider ecosystem. And sometimes that means that there's just a lot of stuff happening and sometimes, and sometimes the schedules happen to align in such a way where they just all happen at once. And that necessarily means an unstable release it actually shows that, from my perspective it shows that there's a lot of people interested in making fedora the best it could be. And that actually I think is a very heartwarming sentiment and really is a testament to how successful our community is that people want to do this sort of thing. And we'll see like as we go forward. I think we'll at least like in my personal roadmap. Yes, I did this big change, but I have plans about how to iterate and build on it and make it better that are not quite so like huge or earth shattering levels of change but we'll see like I want to build upon what I imagine many people who have made these very big changes are in the same boat they're trying to build this foundation to do something better and build upon it because that's all we do like we we make these changes because we have a vision of like how we want to move the Linux platform forward and this is this is how we do it. So I'm actually very excited and I'm, and I think that if we hit this like five year mark basically every five years we wind up having a relatively big release, which has a lot of foundational technology that then gets iterated on and built upon I think that's not bad I think that's actually that shows that people are doing it thoughtfully. Like if we were having every single release, we were having massive breaking changes, and then nobody was like reflecting on incrementally building fun I think we'd be in big trouble. So, so I think we're doing okay. And I'll toss it to Fabio let's see what he thinks about it. Well, I've been mostly thinking about how to how the changes we're integrating with Fedora 33 are a bit more do have the potential for breaking a bit more things than usual I think. So, I've not really been thinking about what to do for 3435 and so on. But right now I'm just just a bit relieved that things don't have haven't been blowing up. For Fedora 33 yet. Maybe except for for me seems like stuff. Well, I've been helping out by by fixing a few dozen packages in there. So, yeah, and it's a lot. Igor and I did like 51020 or so. And I think the tally was like, almost 1500. So we got a third of the way through before mastery build. And so like that was, by the way, if you think that it's easy to change two lines in every spec file. No people do those two lines differently in every spec file. And so I have to build and test every single one of those locally. And that makes it very slow. It makes me wish I had a coji to do all this stuff in. Yeah, and I'm kind of surprised that switching to Java 11 from Java 8 didn't break more stuff. Which actually worked out quite well. I think there is one remaining problem with free IPA where one Java component isn't working right. But the same version in Debian works correctly. So we're not quite sure where the problem is. Yeah, but I think that's that's been worked on. So Java 11 is looking great. Matt Booth has been working on integrating back into main repo from the models again. So that's looking great. And yeah, there's a lot of stuff that are still being worked on. Anybody want to jump in? Yeah, actually, so I wanted to add on to what David and Neil said about this cycle of, you know, bunch of stuff landing, stabilize, whatever. And I think Neil's right that it's been like a five year cycle, but I think it's getting shorter. I think we're going to have to adapt to a shorter cycle and we're going to have to do that by, you know, CI, automate stuff, make things easier, you know, just do a lot of stuff so that our pace can increase without sacrificing that quality or that that stability. And I think that's going to be a big challenge for the next, you know, two or three or four years that we can get that going. I'm also really excited about the Lenovo stuff. I'm interested to see how that's going to affect our community. Are we going to see an influx of users? Are we going to see an influx of contributors now or both? I hope I'm hopeful and I'm really interested to see what happens from that. Very exciting. I think that's the biggest development in Linux in the past decade, like that we're now like, I mean, 10 years ago, there was the triple EPCs with the network remix and stuff like that. And that didn't last very long because Microsoft killed that with a stone fist. But you know, this time around, we have some very real cancer success. We have a relatively mature Linux desktop. And maybe my personal hope for that is that maybe more people will start focusing on our paper cuts. Because I mean, I don't be the first to admit we've got plenty of those in Nome and KDE everywhere. And like, that's where I want to see us grow. It's very, it's very obvious. And I think everyone knows that. But it's just a matter of time and, you know, effort to get those things. And sometimes they're hard. Yeah, a little paper cut that's like, Oh, I'll just fix this in this afternoon. And, you know, eight hours later, you're looking at something completely different, but it's related to the thing you need to fix. I'll tell you right now, that's pretty much I wound up on finally pushing myself over to do the butter if s change, like the impetus was, we have this space contention issue, and I need to figure out a way to fix. How are we going to do like certain quality of life improvements for preloaded laptops. And every other strategy I could think of just could not be made to work. I've really tried. And I've looked at what other vendors have done and they suck. Like if you look at what System 76 does, your first experience is you have to reinstall your computer, like straight up. The welcome the getting started with your computer literally reinstalls your computer. You do not have a working environment to start from and then customize. So that is an experience I want to avoid. I want to make it as smooth or smoother than what people have on Mac OS and windows. That is my personal goal with these sorts of things. And I think that's I think where we're going to start seeing more people do that with the Lenovo laptop stuff. Do you have anything to say? I don't have much to add. I think one thing that maybe is with the idea to go in faster and being able to make those big changes more often is all our tooling and experience for packages. I think there is a lot of work there that would be cool to look at how we can tackle that. Yeah, we do have a lot of talk around. I mean, Kevin was just mentioning it with CI and all of the efforts around that. And I think that that ties in very closely to just making it easier for us to keep Fedora updated and time more closely with upstream. So things that are interesting to me, which I mentioned in my questionnaire when I first ran for Fesco is the stuff that I am interested in is how do we make it easier for package maintainers and developers to have their projects built and integrated into Fedora. What are the sticking points right now that we can make easier? And we have a lot of efforts underway with that right now. And every little thing that we can think about as a project, like before this, I was in the RPM AutoSpec talk, which is really interesting. And you think about it, it's like, oh, well, it's just, you know, this is sort of one little thing in spec files. But all of those little things added up will help us as a distribution and as a project just move faster and also have more reliable builds and reliable output. Like tested output. The CI efforts help us with that quite a bit. I know we recently had some issues with tool chain problems. Neil, you had mentioned why don't we use side tags for that. So that's like another thing. We should categorize certain aspects of the project. These things are more important because they directly impact other things, whereas a new build of nano might not necessarily impact everyone. And, you know, so not everything is created equal, but we need the right tools to do this kind of stuff. So I think we're going to have a lot of that happen more so throughout this sort of stabilization period. And I think I've talked over some questions. Let's see. Let's see. So Mike Rochefort asks, relationship between Red Hat and Fesco has been over the past few years. And how do you expect the relationship to progress over the coming years? I feel like this is a question I really can't answer because Yeah, I think maybe maybe we should have everyone's take individually here. Because yes, I think it's going to be different a different view from everyone. So the light for me, you know, I'm employed by Red Hat my manager has told me numerous times. I don't expect you to be on Fesco and also representing the interest of rel, like you are doing this as part of the fedora project. And this is a fedora thing. So fedora first upstream first. So I can say with confidence that my role in Fesco is purely because I want to do it and my interest is to make fedora better. Fortunately, the tie with with Red Hat allows me to do that as part of my day job. I don't I know that not all of us have that ability to to the same extent, but I, I feel that Red Hat has over the years deferred more to Fesco decisions for what, you know, upstream engineering direction looks like for the project. And I have not seen anything come in where Red Hat will say, Oh, Fesco, we don't really agree with this decision you made. It's more they recognize it and then they understand that they have to start planning for something different in rel if they are if they need to be different if it didn't, you know, a change went in that they don't want in rel for instance. So I, I think we'll continue to see, you know, the support for what we do from Red Hat but they don't, they're not from my point of view they're not looking to take over and sort of drive things if that is a concern anyone has. And that's my view so over to we're doing the same order here I'm going to the next person in my view here which is Neil. So my perspective is a little interesting here because I don't work for that contrary to what so many people seem to think it's frighteningly bizarre how many people think I work for that I really don't. I don't work for red hat I don't work for Suza. I don't work for canonical. So like, at least not right now at least I don't think I do. But anyway, my perspective on this is that I think, generally speaking, relationship the relationship between red hat engineering and fesco is positive but weak. So, the, the general communication between red hat enterprise Linux engineering and fedora is extremely weak. It's pretty difficult if I wanted to solicit information, feedback or advice, or I just wanted to like get, you know, some sense of how they felt about these things. It's actually pretty difficult without some back channeling which I don't like doing. I'm good at it at this point but like I don't want to I'd like that stuff to be in the open. In general red hat supports what fedora does and with some very, very minor exceptions. They actually are supportive of the changes that we make. Like they, they recognize that we're making these changes to benefit the community to benefit the fedora project and they also use it as an opportunity to take stock of what decisions they're making and start like do they need to reevaluate their own choices in life. You know, like it happens like an example that I will probably call it to like my mother has changed. I did actually talk to like I did have some conversations with people at red hat about it before I proposed it. I've had conversations about it actually for about a year before I proposed it. I've had conversations with a number of other people with all the different spins. I've had conversations with the upstream projects. Like there was a lot of work that went up front before I actually proposed it. In general, this what this proposal has done is it sparked an interesting conversation about people's expectations about how storage should work and how it should service the overall computing experience, which I think is actually a good example of no matter what technology you use. And this is something that I think everyone cares about. They, these changes and these sorts of things help bring those conversations forward to make people think about it. And, you know, what I've been particularly happy about is that my employer data. Actually, the reason I ran for fescos was they said they were supportive of me represent working in fedora representing fedora's and also, you know, being involved in the project because like I didn't want to do this without, you know, being able to figure out if I could squeeze time for it. My manager, his manager and his boss were all very supportive of me doing this. And like I actually want to see that kind of attitude spread and it's nice to hear that from David that that's basically the same experience he's had within red hat, which, to be fair, I expected that because like this is red hat and I expected to be super cool about working in fedora. But like, it's still nice to reaffirm that. And it's also nice that like where I work at Datto, they're the same. If you're working in an open source project, and it's an open source project that can help you and help the community and help, you know, and help Datto in some way, like they're happy to let me do this sort of thing and that's the way that it's been that's been going. And I'm very, and I think that there we have, while we could go downwards, I really don't think the relationship is going to get any worse between red hat and fedora. I think if anything, it's only going to get better as as we do this and this mixture for fesco this time where it's like, I think almost evenly split between red headers and non red headers makes it, I think a much more interesting dynamic where I think this becomes much more obvious that red hat is supportive of the fedora community, and not trying to do something like strong arming it into doing what it wants. Because, because you know it's essentially, we all have to talk to each other we all have to work with each other we have to compromise and come to come to a consensus. And they're, and they're happy with that process because they know that it helps makes the best solutions that they can even take later to productize if they so choose. So, I think the relationship with red hat and fedora is fantastic. Could it's a little bit on the communications week, but like overall I think it's generally very good. Communication is hard. Ah, yes. Don't I know that. I'll go next, but yeah, I think the same as David, I'm employed by that. So I was surveying you in Fesco, so maybe I haven't been invited to the secret, let's call it all everything in fedora meeting yet. But no, yeah, it's, you know, the way we just like the fact that to be in Fesco or just part of the fedora community is not, is not really something that your manager would would ask you to to do things specifically in the interest of red hat. So obviously red hat has some objectives and some ideas behind it, but it's much more vision and like where they would like the community to go. And if you make this more than like a specific change or you have to block the speed or you have to do what I speak. So that's, I don't know, I don't have like a gun on my head or anything when I want to change this. That's it for me. I don't know if anyone else wants to go home. Yeah, I've got a few things to add. I agree with the with David and come on. But I will add that red hat actually has a clause in their code of business ethics that all employees agree to and that the company agrees. This is the relationship between the company and employees that says if you're working for an open source. If you're working on an open source project, you do not have to consider the interests of red hat above that project and in fact you can do the opposite. It's perfectly acceptable to the code of business ethics, which is great. I think that's one of the most awesome things that any place I've worked says you can go against the interests of the company. And it's for an open source project. That's the way it is, you know, that's good. I agree that the communication is light between red hat or at least officially and and fesco and I think it's always been that way because red hat doesn't want to start like directing things. They don't want to have like if red hat had say a representative that went to fesco and said, here's what red hat thinks. Here's what you should do. And then I think there would be a lot of a strange pressure there. And I think red hat is very cognizant of that and don't they don't want to do that they don't want to influence the project. The upstream project for doing this case. You know, directly, because that's just that's going to result in in West diversity it's going to result in strange consequences and they just don't even want to go there so I think that the communication is light, but for a reason. I didn't think of it that way. I didn't think of it that way. That's a pretty good perspective for in fact there have been times when I really wished it was stronger, like in the past we've had things where we're, we're confused we don't know which which is the right path and I'm like, Well, we have all these smart people and right now we can go ask them but then they're not going to really say because they don't want to influence our decision so you know it's a kind of a double edged sword there. And I'll throw in a story at the end in all the time I've been in Fesco which is since it's been around. I've had one incident where somebody mailed myself and several other Fesco members and said, I would be really great if you decided this for this thing. And before I could even reply to it, my boss replied to that and said this is completely inappropriate. All of you do not answer this person I'm going to talk to their management. Done. And so I mean they take very seriously that you shouldn't be influencing people behind the scenes or through a company relationship like that and I think that's great. Actually fantastic. I've never I didn't really think of it that way. Again, this shows that I'm the outsider I have no idea how this could be perceived and like that that makes a ton of sense to me so I mean, I think the only thing that I I kind of from a communications perspective I think that when sometimes when red hat proposals come in for changes and stuff like the storage instantiation Damon change that came into F 33. I was super confused for what the point of the thing was, because it's not used by anything it was a system wide change, and you weren't they weren't even proposing enabling it and it doesn't do anything. And I felt like, I mean yes I can approve it because you're just literally adding a package of doing nothing. But like, what was, what is the point of this what are you trying to do with this what's your vision. I think that's the part I tend to feel like is missing a lot from a lot of change proposals like if you look at my butterfly change there's there's actually a fairly a concrete vision laid out in there, and a lot of good change proposals include this information. In the benefit to fedora there's a somewhat of a visionary statement involved in there. And I feel like that's one of those things that I feel like I'm missing from a lot of a lot of change proposals from red hat or otherwise but like the storage instantiation Damon was particularly egregious because I had no idea what the point of it was. And so like, that's the kind of stuff that can help us factor into like our own community decision process. So, like just understanding the bigger picture, I think helps a lot. I feel like I miss most of time when it comes to red hat employees who make change proposals, or even other people it's not specifically red hat but like, I see it a lot more with the with proposals of bigger changes by red hat employees. I think because they expect that everyone kind of already knows and we don't. And so, yeah, I had employees who are maintaining or doing something for their job, and they're not interested in the community for whatever reason they don't have time or they're, they're just want to focus on their work. And they're sort of trying to get things upstream but it's kind of a secondary goal to their goal of, you know, and I think that happens with other people to from other companies, you know, Oh, get this in fedora all right I'll get it in fedora. That's a check mark, not a, you know, I'm wanting to maintain this thing and see it do better. And, you know, that's just everybody has their own level of participation there. Yeah. Things could be better coming from red hat employees a lot of that is leading up to what will eventually branch from fedora to become the basis for a new major rel version, and some teams at red hat are better participants in fedora than others and when you see changes like that that don't really make sense like that storage daemon one. For me, like having having been involved with this for a while I, I sort of read it I was like, Oh, this looks like groundwork for something that that red hat wants to explore with Well, I don't really know the details of what that would be, but they know that if they want it in rel they should work to get it into fedora so that's why they're doing the change proposal. And so, Ben made the comment in the chat that, you know, while we're not held to, you know, rel's every need and we don't have to think about that with our decisions. We do need to remember that rel is sort of a downstream consumer of fedora and provides us with a lot of user types that we don't necessarily see every day. So, I think that's the only thing in the back of my head for that. I don't really know how to improve that interaction with with red hat employees doing change proposals that are kind of weak. I don't, I don't really know how to approach that and how to how to improve it but maybe we can as a project. And I see, let's see. We made it to about 1145 my time before we got a modularity question so that was pretty good. I'm happy with that, but people. Do we want to do we want to take it or do we want to take it pretend like we didn't see it. Oh, I'm going to take it. It's more fun this way. But yeah, when it comes to influence and vision to red hat proposals and requests. I don't want to say directive come, such as the recent one for modularity come down from saying this is what we'd like you figure out the details. Okay, so I think this is a little bit unfair. It's a little bit perorative of how this is being described. There's, there's a lot of the modularity proposal currently that's floating right now that that is trying to be worked on is essentially was a last minute request by one of the fesco members to produce a generic policy. So that the enterprise Linux next project eln could start doing default module streams because he essentially wanted to make it so that whatever policies implemented is essentially usable in fedora as well, which I think we all felt was fair. Because we do eventually want to see that technology stack succeed in some way, like resolving the, the some of the problems and making it usable for the use cases where it can really help make the platform better is definitely something that we all want to see. The way that it, it seems to be is that there's a little bit of tension and frustration. I mean as an outsider, like I tend to have these conversations with these people talking to them trying to shepherd these things through into the right path and the happy paths. There seems to be tension and and and a little bit of frustration, but they also have a genuine desire to try to make this the best possible thing for the community at large. The people that worked on the modularity technology stack know they screwed up with the way that they brought it into fedora the first time. And they are trying very hard and very earnestly to fix that as they can, keeping in mind their, the limitations that they have today. And I know that at least I've had conversations with them about how do we strategize to pull away from this from some of these broken paths into making this a much more successful part of our ecosystem and also keeping in mind that I now have personal and professional experiences where modularity has been extremely helpful to me in the way that it that it works that I do want it to succeed and I want it to be there. And it's it's hard. These are these big fundamental things we're like, we're essentially changing the world in a very big way. And changing the way you think about this and the way that you want to do this is very, very hard and getting there is even more difficult. Like so, I think it's just going to be one of those long hard paths to get there. But I'm optimistic that things will in fact get better. And yes, it is much better than software collections. I just software collections hurt. They are very painful. I don't have anything else to add on what you said, Neil. It is a difficult thing to deal with. But I think overall we we do want to see some success without reintroducing things that cause major problems for all users and it's just it's a tedious process. Because it's a it's a tough puzzle to work through, I think. Anyone else have anything to add on modularity. No. Okay. So I see those fesco steer raw hide as much as release. Are there different criteria for raw hide changes to be accepted. Well, not not really. I so raw hide is sort of anything goes with some exceptions. It's evolved over the years. The general expectation is, if you're going to introduce a large change impacts a wide range of users or packages, you should do a change proposal. It's going to land in raw hide first. And then we stabilize there and then release from that. I don't know if anyone wants to add any clarification to that but that I don't view it as like a separate process at all. I don't. I don't think we ever have really but I think I don't know if I've ever sexualized raw hide is something intrinsically separate from fedora releases. Like, it is a rolling release, but it is also the release will be right. So, yeah, so like from from that perspective I think fesco. I think fesco always considers raw hide but we always consider raw hide in the context of a fedora release. So for us they're one in the same. So, yeah, that's a good point from Ben in the chat by the time of release branches it's too late. So, whatever the current release is raw hide is building up to become that next one. So the change proposal processes for what that next release will be that's the cycle that we're in. Hey, Neil, you know, like more than the 0% I know about open Suza but maybe there's maybe some people view like see open Suza leap or tumbleweed as being like distinct things we don't really do that with raw hide. The ongoing thing. Yeah, for in the open Suza world. They don't have a normal stable release anymore. So the way that they do it is everything goes into what it's opens as a factory they're equivalent of our raw hide tree and factory runs through automated testing. And when it validates on that testing, it is snapshot it and pushed out as a tumbleweed snapshot release so open Suza tumbleweed is a stabilized validated snapshot of factory. And then every four years on the dot three and a half really but every four years on the dot open Suza tumbleweed is then branched to become Suza Linux enterprise and Suza Linux enterprise is developed in the open with the community. And then once that is stabilized and released that becomes open Suza leap and Suza Linux enterprise with package hub. And that is like that that model means that you have to consider open Suza leap and open Suza tumbleweed as fundamentally separate things and they do wind up having slightly different policies, slightly different way of handling things. So it doesn't map to how Fedora does this and so that's. So from the Fedora perspective, a branch is just a Fedora releases just a snapshot of raw hide. That's all it really is. And so from our perspective, we look at what raw hide is going to be to kind of project what a release will be for users, and we try to make a decision based on that. So from us it's all one in the same. So it doesn't directly compare to how the Suza world does it. But I can see how people might mix the two in. Yeah, there's a lot of changes that happen in raw hide that do not go through the change proposal process if that was required for everything none of us would ever get anything done. That's why we have like the process to become a package maintainer we trust that overall you know what you're doing and what your responsibilities are. So when you hear a Fedora developer talking about I got that change in a raw hide or something like that. That's just, you know, sort of the nature of ongoing development and not something that needed to be formalized as a change proposal. Trying to read. Have there any more questions from people. Just a few sentences. I want to add to what David said. Yes, I mean, for, for most small changes in packages that packages do in their day to day work and their day to day contributions. There's an update policy for that. Most people don't seem to know that but there's actually an update policy. And it clearly states what updates you can do safely in raw height which updates you can do safely in stable releases and in branch releases. For example, it tells you that you shouldn't do so nine bumps and stable releases and stuff like that. Just the basic principles of making sure that you don't blow things up by pushing broken things somewhere. So it's following the update policy for small changes is usually the way to go and the bigger changes. There's the change proposals. Like to add a comment to what you just said that that's very good to update policy. So name changes, things like that. When that does happen in raw hide and catches people by surprise. I want to remind everyone to not assume that package maintainers were doing anything deliberately. Oftentimes it's a surprise to them as well as you because something may have changed in the upstream project that they did not catch while they were doing updates while they were checking things. And so please, please don't assume that people were doing things deliberately to bypass these processes that we have many projects undergo a lot of changes and package maintainers do a fantastic job. Staying on top of that restructuring of code bases build systems things like that. So I mentioned that because I see mailing list comments where some people, you know, they're kind of frustrated and then, you know, they're, you know, that's it's very easy to fall into that trap that that assuming people are trying to go around the policies and rules. What are fesco peeps up to these days non fedora related one of there's something outside of fedora. Well, not a whole lot, given there's a pandemic we don't, we don't have a lot of things that we can do around here most things are closed but I will say that I had a for me I had some new antennas installed on my roof. And the summer I bought a bicycle. It's been over 15 years since I've ridden a bicycle so trying to do that again. I mean, for me, not a lot I can do because, again, as David said, I'm forced to be a shut in that that makes life a little difficult. I mostly am actually getting back to playing more video games and stuff because like I have a huge backlog of video games that I have been wanting to play for a while and I haven't had any time to. And like I'm really using my Nintendo switch a lot more and like I've been playing. I just got super pepper Mario the origami king and I'm having a lot of fun playing that. And, you know, I think it's mostly that I'm trying to relearn how to relax because I haven't done that in a while. And that has actually turned out to be surprisingly difficult. Learning how to relax is very hard. Yeah, I'll just jump in with a few sentences. Well, I've spent most of my time in July and sometime in August by fixing Java packages and fixing CMake changes. The university has been total chaos this semester, so I didn't have much to do for that. And I'm hoping that it'll be better in autumn. And yeah, I've been cycling too. So that's been nice. I'll go next. Most of my time I spend with the kids. That's the joy of having small ones. So yeah, going out with the family, enjoying the kids. But yeah, so I don't have exactly the same surrounding as Kevin, but I have like mountains that's pretty fast. That's a good way to relax. That's my way to get away and get far from the screen and keep going. It's been this sort of pandemic thing going around. So we just moved to this very lovely house in Oregon about a year ago. And there's a ton of landscaping and outdoor things that we have backlog work on. And of course, reading books and watching shows and all the things that other folks do. Yeah, it's kind of hard. It's kind of interesting since I spend most of my time at home anyway. The pandemic hasn't really affected me that way, but it has affected me in other ways. I mean, just interacting with people you can see everybody is more tired and, you know, frazzled and impatient. You know, it's difficult in these times, but you know, everybody should try and relax and where they can to be refreshed and not burn out. Okay, I don't know how long this session runs. My assumption was an hour. It runs as long as we're still in here. Oh, really? Oh, okay. Technically it's over, but it doesn't quit until we all leave. Okay. Technically lightning talks have started two minutes ago. Okay. Stephen is telling us to go away now. Okay, well, thanks everyone. Thank you for the questions. You know how to find us on IRC and email. Enjoy the rest of Nest with Fedora.