Flock 2025 FESCo Q&A

[applause] >> So, we will start with a quick intro. Everyone will introduce themselves and then we will do Q&A. >> Okay, so let me start. Hey, my name is Tomáš. I have sunglasses because I'm the only one without the real glasses on this team, it seems so. So, hi. My name is Tomáš. I am part of the Community Linux Engineering Team at Red Hat and I'm part of FESCo for fourth term or third term? I'm not sure entirely. And that's about me. I'm happy to answer any questions you would have about regarding the services that we run, maintain, and with FESCo duties all around. >> Uh so, my name is Bishakh. I maintain systemd in Fedora and I have been in FESCo for I think 7 years now. And last year I was working on uh reproducible builds and they've been has been merged uh and stuff like that. >> Uh hi, I'm Kevin Fenzi or people may know me as Nirik. I've been on FESCo since it was the Fedora Extras Steering Committee back in the day. So, I am old in other words. Uh I work on Fedora infrastructure. I'm on the Community Linux Engineering Team for Red Hat also. Um and right now I'm mostly working on our big data center move. Everyone ready for the big data center move. So, that'll that'll be exciting and it'll be we'll be in a much nicer place once it's done. So, that's me. >> Thank you. I'm Fale. I have been in Fedora FESCo Engineering Steering Committee for the last 6 months. I think I'm the youngest member in the in FESCo and I've been in the Fedora project for 10 years probably. Mostly in the packaging side but also at a certain point in the ambassador side as well. Um I do work for Red Hat but doing completely different things. So, effectively this is I am here only as a community member, not really as a Red Hat person. >> I'm Stephen Gallagher. Not exactly sure how many years I've been on Fesco at this point, but it predates Matthews term as FPL, so Yeah, and many. >> Wait, really? That's it? That's That's all we That's all we get to know about you? >> Okay, all right, all right, all right. My name is David Cantrell. I work for Red Hat. I'm closing in on 20 years there. I've done a lot of stuff, worked on many projects. These days I'm on the software management team, which is RPM and DNF and sort of that adjacent software. Actually, yeah, I I've lost count of how many years I've been on Fesco, but I joined after Flock in Budapest. That was when I when I ran. So, I've been on it since then. >> So, hi. I'm Neil Gompa. I've been around in Fedora. I don't know, like I think according to the earliest records I have of me being a contributor was 2006. So, quite a long time. Mostly [snorts] in the factoring software stuff. And I do a bunch of little things here and there. A little thing you might know called Fedora KDE. It's a thing that I do. But, I've been in Fesco since Fedora 32, 2020. So, that's this makes it my sixth year here. And yeah, I guess that's kind of it. >> Hey, I'm Fabio Valentini. You probably know me by the nickname I go by. It's Decatone. Yeah, I've been contributing to Fedora for a little bit more than 10 years now. I started packaging the Pantheon desktop where Neil mentored me. Uh did some Python packaging, Java packaging, then I gave that up and now I'm basically the Rust guy and have started uh doing some cryptography stuff with OpenPGP and something not really how I ended up there, but yeah, that that kind of happened. Yeah, thank you. Yeah, um I've been on FESCo with one break, I think, for the past 4 years or something. And on Fedora packaging committee for like 7 years and yeah, now I'm Yeah, and now I'm basically the Rust guy, so you're welcome. Um I won't make any rewrite it in Rust jokes, so don't worry. >> So, we're going to take questions from here, the audience live, but also for the people that are attending uh online uh on Matrix. So, any questions so far? Okay. >> Uh let's talk about the elephant in the room. Um as Jeff told about his focus in AI and, you know, um what's FESCo's thoughts on it? Where which direction do you folks plan on taking this? >> Uh I'll take a quick stab. Uh I think I'm not a a complete AI skeptic, nor am I a complete AI is great and does everything. I think we have to be very careful to figure out how we can use AI, you know, ethically and energy efficiently, and yet also it using it in a way that is beneficial cuz just shoving it everywhere is not the answer. The answer is to look considerably, just like any other tool, how can we use this? Where can we use this? Where is a good place? And I think there are places and I think we just need to figure those out and we need to be careful not to to do the wrong thing here. So, we should we need to be cautious. So. >> Anyone >> Uh yeah, I I like to echo that as well, but also mention that we we had talked about in the the council with the 2028 vision the um sort of having Fedora be you know, carry the software and tooling and kind of focusing on the engineering aspect and having it be ready for developers that are wanting to work on AI type projects or tooling or things like that. So, I I I share Kevin's sentiments, you know, just kind of you know, we need to be cautious and and careful and stuff like that, but then on the engineering side like preparing Fedora with with the right tooling and and things like that to make it a viable platform. I I think is at least the the thing I'm concerned with. >> [snorts] >> Yep. So, I'm extremely optimistic and I will talk I see the this question to be twofold. One thing is as we as a project talk about us using AI and deploying it in our infrastructure with our data. That's one fold of the question and there I go with Kevin and what what has been said. And there I am extremely optimistic in self-hosted AI which is us as the developers and people who run their own computers are able to run run their own models locally on their hardware. And that's something where I would like to see Fedora being first class citizen and helping AI developers to be able to spawn their machines, do their development easily, safely. That that's my stance. >> So, uh I'd like to give a little to be a little bit more specific in my answer cuz it's it's easy to say, "Oh, yeah, let's you know, I don't want to be unethical, but I also don't want to uh it I think to to put a put a line on it. I I think uh I view AI as a potentially useful tool that should assist human beings, and I don't think but I am a pretty hard line against the idea of AI replacing any uh any process entirely without human involvement. Um I don't think that that is a good use I I well, I don't think that can lead anywhere good. Uh But, I do think that there is a there is a a gray area, you know, how much how much coding assistance is okay, how much automated detection is okay. And I think like I said, I think the answer there is that anything that allows for humans allows for making it quicker for a human to respond is a thing is an opportunity. Anything that tries to take humans out of the equation is a risk. >> Um and I agree with pretty much everything that was said, but I will add that um in the previous talk we there was a question like what is the role the position of Fedora, and for me uh it is the place where the like the development of the Linux technology happens. Uh and um I mean, we are the leader in that. And if we want to remain in that position then we need to I mean, we have no choice but to embrace stuff that comes. So, like for example, the we have the trusted computing stack, and people are making efforts to make it possible to use it in Fedora. And either we do it and allow it, or we uh stop being used, and people move on to something else. And with AI tooling, it's I think kind of the same. >> So, my thought about this is ultimately, anything that we use still has to retain the quality of being able to support accountability for people. So, um I vaguely remember, and I'll probably misquote this, but like at some point IBM used to have a thing where they said, uh you know, computer because computers can't think, like they can't be accountable. So, a computer should not be making a decision for you. Um and I don't remember what the exact quote is, but like the sentiment makes sense. Uh and so, the thing that kind of concerns me is how people talk about um machine learning and AI technologies as a reductive force rather than uh an additive force. Like it does It's not a multiplier. It's a way to reduce costs or all this other stuff. It's the wrong From my point of view, it's the wrong way to think about machine learning technologies in general because if because the the cost reduction is a one-time gain, and then you have a many times fail coming afterwards. So, when we talk about bringing AI/ML into Fedora, we should be positioning it as an additive force for supporting all kinds of things, not just, you know, code and and things like that and translations and whatever, cuz those are the easy parts, actually. The hard parts are stuff where you're trying to augment people light people's lifestyles and and integrate, you know, improve general quality of life. Those are the things that I think where you have a much more diverse user base, and you have a bigger pool of of consideration that that we need to account for as part of bringing in this technology and exposing it to more people and generally in the commercial space, I mean I was at Red Hat Summit, I was at SUSECon, I was at SCALE, I was at a bunch of places. In the commercial space, this is not discussed and I think this is a big part of the negative framing around AI/ML and we need to kind of reframe it in a more of a quality of life enhancement thing. Um and that means bringing the tooling in and starting to start the conversations on using this tooling that we have in Fedora to improve people's quality of life. >> Personally, I do see the idea of bringing all the tooling, the AI tooling or toolkits into Fedora a great idea. We should do it tomorrow if possible today. Um but >> Oh yeah, yesterday. Sorry. I missed the memo there. But the other point is the usage of it. So, we have seen a long conversation a while ago. I think it was roughly a year ago about the main metrics stuff. I think that we should not go that way again with the AI in the sense that as long as we have things that we are sure enough that are safe and do not share any data outside the system and everything like that, then they can be enabled. But I would be way more careful on the usage of AI baked in the system just to avoid things like Microsoft Windows Recall, however that thing is called. I would personally not endorse anything like that anytime soon. So, while obviously giving the user the ability to develop AI software, that's absolutely one of the things Fedora should do. >> Any other questions? >> Oh, no. Oh, god. >> [snorts] >> Hi, guys. Uh Matthew and Jeff have both talked about Fedora Strategy 2028. I was curious in your day-to-day activities as FESCo members, do you think about this or is that somebody else's thing? >> Oh, boy. You do not ask the nice questions, do you? Uh I I kind of keep it in mind a little bit, but a lot of the Fedora Strategy 2028 stuff doesn't really fit with what people are actually working on, so it it doesn't There's not much to align on when it comes to the day-to-day work of us processing Fedora changes or steering technical direction and things like that. We do even have a uh a little question that shows up on the change template of like, "Hey, does this align with any of the themes for Fedora Strategy?" Al- almost universally, no one fills it out. So, like So, like I think uh the question to ask isn't to ask us whether we think about it. The question is, does the larger community feel like the strategy actually makes any sense for them to incorporate it into their thought process? And I think right now, to put bluntly, I think the answer is no. Most people just ignore it. Uh and so, that's something that either is a misalign- alignment from council community or the community doesn't see anything from it or there's no visibility. There's a There's a myriad of potential causes for that and maybe that's something to look at, but it is not something that from the FESCo day-to-day, at least from my point of view, that it comes up even though I am thinking about it, it just I'm not going to force people to align it to a Fedora Strategy goal. That that just seems kind of silly. >> Yeah. >> I probably have a different take on it. Um So so I am I'm the engineering representative on the Fedora Council. So I do think about this more than Neil does. But Neil has a point that FESCo I mean we meet weekly for an unbounded length meeting. >> 100 minutes officially. >> Yeah, and and we do that because we we process you know, very technical things that come up, you know, like we really get into the details. That's kind of the point of of the committee and we we ask each other questions. We ask the the proposal authors questions. We really try to get in there and make sure that we have everything covered so that we can vote on it appropriately. So in that respect the day-to-day I I don't I don't think everyone on on the on FESCo is really thinking about 2028, but I'm thinking about it probably more than than the others. I don't know. I'm going to take a guess, but only because I'm involved with the council. So I've I've got that in the the back of my head as well. And I think that a lot of the stuff that shows up broadly aligns, but it it the end of the day a lot of our our tickets that we're processing change proposals are So so very minute details. They don't really have a direct alignment, you know, it's just it's it's a necessary thing that has to be done or or something like that. But yeah. >> I'd actually like to turn the question around a little bit on the council and ask what exactly they would like to see from FESCo in terms of trying to enforce uh an alignment on strat. >> Steve, we have our NDA tomorrow. >> Yeah. Uh yeah, well, I consider that Yes. Yes, consider that question submitted for tomorrow, but I I I'm I'm entirely sure what it FESCo is is more more a tactical body than it is a strategic one. Uh you know, the council sets Fedora's strategy, but we we we we manage the uh the minutia, the day-to-day. And so, it's a lot harder. You know, we we need perhaps a little more guidance from the council as to what you know, do they want us to decline uh change proposals that don't align? That's I I don't think that the I don't think the answer to that is yes, but I don't but I I think we need a little more input. >> Do we need to make people start filling out that section about the strategy then? >> The mic. >> Um So, I think that the strategy is more about the community. Uh I think we're doing kind of well on the technological front in Fedora. Uh the but we are struggling with growing of the community, and this is um uh >> [snorts] >> I think that this is something to that we need to I don't know, like um we should smooth the sponsorship process and make it easier to extend to new hardware and stuff like that. And I uh this all ties back to to having new contributors and more contributors. Uh and I don't think this is the FESCo is not really directly involved in that. >> Uh I'll add to that that FESCo is kind of more reactive body than a proactive body. FESCo doesn't have like can't say, "Oh, we're going to do this, and we need these 12 people to work on that." cuz we don't have 12 people. We have us volunteering to do things. Uh so, I think it's very difficult from where we are to uh we're reacting to things that the community is bringing to us to do rather than proposing new things to do ourselves. So, I think it's it's difficult for us to to change that flow. It's it's got to be a community-driven thing that the community wants to bring to us things that more align with that uh that goal, I think. >> Questions? >> So, at the end of last year, FESCo undermined the trust of the community in the Fedora as an organization. Um in the recent election spills, I didn't see anyone make mention of that. I would like to know how FESCo is going to um fix the problem they have created within the community um and how they're going to improve moving forward. >> So, to turn the question around, um uh the council uh in cooperation with FESCo to publish a statement uh 2 weeks ago that uh uh I mean, the the core part of the statement was actually uh written by us, so it's um uh drafted by us. Uh and uh it announced uh um outlined some specific steps for uh improvement. Do you find those convincing or do you do you think that something is lacking? >> Um that was more about improving the packaging process, not FESCo as a committee, and FESCo in their openness, um and there was a few bits and pieces there, but I am waiting to see. It's been nearly 6 months. >> Yeah, uh to kind of elaborate on that, I think the the council statement, one One things they mentioned was that there was no process being followed. It was sort of like made up as we went along and that was a large, in my opinion, large part of the problem. Uh and I believe the council statement or the statement uh mentioned that Fesco should actually have a policy for these sort of things. So, I think in in the next, the upcoming weeks, months, whatever, there should be policy proposed, discussed in the community, you know, uh consensus gathered on it and then there would be an actual policy on that. And I think that would help greatly to you know, handle those sort of concerns, but Who else? >> Hey, um completely unrelated, um how do you see emerging architectures like RISC-V? >> Emerging architectures is a good way to put to put it put it. Um The I think there's an interesting opportunity over the long tail, uh the you know, the mid-to-long-term future that there could be something interesting to come out of it. Um consider myself pessimistically optimistic about the nature of emerging architectures. Um so, I've kind of gone through this rigmarole uh in some respect with, you know, the ARM stuff and that has not gone on as well as I think many people would have hoped. Um the RISC-V stuff, uh so, in as RISC-V stuff has come up, I have been engaged and I know a number of other Fesco members have been engaged on multiple [snorts] fronts, both in Fedora and in upstream spaces and inside spaces. I know I personally have been involved a little bit in the upstream RISC community as well as in the KDE spaces as well as within the Fedora context for for this. Um the general thing I see from this is I am very very very concerned that RISC-V will turn into a smorgasbord of disconnected puzzle pieces that we cannot assemble to something that can be useful. Um I do not know how it will actually turn out, but this is something that I am wary about and trying to see how this will unfold. >> If I may, just one small addition. You you called yourself pessimistically optimistic. I would I would phrase it as, if I may, possibilistic. It is possible, but many factors have to come into play. The ISA specifications, the RISC-V ecosystem, and so on. >> That's That's a technical way to phrase it. I was referring to more of the emotional way I could perceive it. >> That's fair. Totally fair. >> So, I think that looking at architectures, we have a few that are nowadays very predominant in in the market, and obviously we have to serve them, like x86, 64, ARM, those kind of ones. Then we do have some niche ones, such as PPC and S390. And then there are the emerging ones. And I think that the reality will be that we will need to balance uh the willingness to be first at supporting those architectures, which we will not be first, probably, because other distros are leading the way on those kind of things. But in the other hand, also the complexity that it brings to the project to support one more architecture, and the burden that puts on every packager in the community. So, I think it's important for us to to find that balance. Um I'm not sure if RISC-V is yet to that point uh also because of the fragmentation and the fact that we do need to have build servers and all the other stuff which are some kind of issue. So, I think that I personally don't see Fedora on 15 different architectures like other distros, uh but I would hope to to see Fedora on a few more. >> Um so, I agree with the like the balance thing, but I think we should to put it down on the scale of being uh of accepting a little bit more risk than we would like. Um I think that the like for example the integration of the Apple uh stuff um uh I mean it's a bit on the side, but it it it turned out to be quite useful and good for the project and uh like delaying forever until we are sure it's safe is not really a good strategy and I think we should uh try to move forward with RISC-V now even though we know that the hardware is lacking and there are many many issues. >> I'll just I'll I'll just add to what was said uh mostly by Neil and there is like a a I just hope we will not end up in the same space that we end up as a project with AR64 where we were one of the first distributions that had stable AR64 images, but the only hardware you could run it on cost tens of thousands of dollars. So, I just hope we will not end up in the same space with RISC-V because that just cut us off from the potential contributors who are running on those architectures. >> Uh one thing I notice with emerging architectures um in RISC-V like um similar to MIPS uh you know, continuing that where uh and and even with ARM um the the those those architectures have lacked a common hardware platform-like design. Um so, at the end of the day, to to get good buy-in on a platform, you need to put systems in front of developers. And it can't be the fragmentation of embedded devices and things like that. Um and and I look I look at MIPS. MIPS kind of failed that way. There was no reference uh platform CPU. You know, great, it's open. Um but IBM tried with power. Uh they did the chirp thing, and then Apple went and did prep or whatever or I've got it backwards, but again, you had no you had no common platform. And and at the end of the day, everyone's using an Intel system because like it's the PC as much as we hate it. And your PC is the same as my PC, you know, it's like there there is some value to that and getting systems in front of developers. So, I hope that with RISC-V, we have some coordination in the hardware vendor space where we get some designs like that. You know, I know they're going to want to vary, but I think that's the the big thing that they need. Like ARM failed at that, and they don't care either, but they they just didn't they didn't quite get to that point. So, I'm hoping to see that with RISC-V. >> So, what quick one there's another uh working group that's working on RISC-V as well. >> Which is great. That's that's great to hear. Yeah. Yeah. Yeah. What? >> Whatever you said, you didn't >> Yeah. Okay. Yes, you you said Yes. Yes, sorry. Uh yes, you said that uh uh they're they're uh they're working on that uh server group upstream. It's all um open and and things like that, which is what I was agreeing with. I did this backwards, jeez. Okay, sorry. But that brings up the point of the problem I kind of have with this is that yes, there's a server working group, but what about the actual side where people work on the systems, the client side? One of the massive failures from my point of view for ARM was that they basically decided that they didn't really belong as a steward of this and didn't develop and enforce a reference in which every kind of client premises device, as well as the server devices, had a basic level of interoperability where we as the operating system vendor didn't have to care about all of the minutia to even get the systems working. The Oh, let me finish. Things have improved in recent years, but it is still a mess. Between things like device tree and weird U-Boots and stuff like that, like that's the kind of stuff that makes that adds hills and mountains to to that maximum adoption. And I'm saying this as the Fedora Sahi remix developer, this is the worst part of enabling an ARM platform is dealing with that part. And it doesn't scale. We know it doesn't scale. So that is the part that like I want to see from the RISC-V side to acknowledge and fix. >> And the community is learning from trying to learn from ARM's mistakes, so we'll see how that goes. >> Was it a question here? >> No. >> Okay. >> Um talking about community initiatives that are a bit on the technical side of things, what things and to what extent would FESCO like to be involved in A requirements evaluation and B the democratization of the participation of community members in those projects. Uh take for example the ones that Fedora infrastructure takes uh like the 4G move. >> I think that's probably I mean it it's not bad for us to be involved in so far as we kind of are the representatives of the technical community of it. Like just like I would say mind share should be present as part of the representatives of the content community like the the design teams and stuff like that. Like and and advocacy and the different functions of Fedora for central platforms should have their part [snorts] in it and that way we don't wind up with platforms that people don't want. Um like some of the ones that we have in place for some of the async communication stuff that has been rolled out despite technical communities not wanting them. Right? We don't want to be in that situation again and again and again. >> And so we I I think that we as a as a FESCo committee should at least approve or validate what what whatever the CLED team which I'm member of whatever we came up because we will for sure consult community. We will for sure have some feedback from people but it would be extremely helpful if FESCo could sit down and you as a all senior engineers so me included could just sign off like yeah, this seems like a reasonable technical solution. This seems like a reasonable set of technologies and this seems like something that makes sense. And I I think that that's a space where FESCo can provide some feedback. Question is how much time we have for that because all of us are volunteering and there is a lot of stuff and the meetings are long. So I would love to see that. Question is how feasible it is. >> Good morning FESCo members. I have a question. Uh nothing bad. >> [laughter] >> Why is everyone already laughing? Um, I just wanted to know since the Fedora project turned 40 in the last couple of releases, what has been the most exciting change that you've seen come through as a group that you've gotten to decide on? And also, what has been the most challenging change that you've had to work through as a group to decide on? >> Oh god. >> Yeah, I feel like I'll go first. >> Yeah, you do that. >> Uh, most exciting change, uh, selecting nano as the default editor. >> [laughter] >> Um, just kidding. Uh, No, it's it it it's tough actually to to to think about it. Like, I I feel like for the most part we're thinking about changes in how to minimize impact on users, but advance Fedora at the rate that it advances at. So, I in that respect, I can view all of them really as as difficult. Um, >> You got [snorts] one? >> I do. >> So, I have one, uh, simply because I'm very new to this. So, in the last 6 months, um, I have, um, the the example of Wayland, um, only sessions, uh, for, uh, genome that will come in the coming release. Um, we will see still have to see the the result, but I hope uh, that it will work well. And personally, doing this uh, decision and conversation, um, I looked back at a lot of conversations that happened while I was not in Fresco, uh, in other big choices, uh, such as the migration to systemd, the first introduction of Wayland, uh, PulseAudio, and many others that previous people, uh, previous Fresco people, uh, have done. And I really admire the fact that those people were able to uh, make difficult decisions uh, that were unpopular at the time and then became demonstrated to be good decisions after years. >> So, I'm going to I'm actually going to go jump in the way back machine here to go all the way back to the very first flock for this one. One of the big outcomes of that very first flock was we We took We basically took half a year off of releases to completely retool the entire Fedora project. We went uh We went from uh a single Fedora Linux release that was intended to be you know, the perfect OS for everyone so thereby the you know, completely ineffective you know, hitting about 80% of the use case of anyone. And we re we retooled that to develop uh uh to to really focus our efforts on a series of additions of Fedora that were targeted at particular use cases. And as a side effect of that even if I'm not about to say that the that that experiment in a technical sense was perfect. It certainly wasn't. But as a side effect of that we actually we re we rebranded Fedora. We retooled the community into actually focusing on these things and I think that more even than the specific deliverables we we came through, I think the I think that exercise in getting people aligned towards towards individual specific visions and targeting particular use cases is a major part of why Fedora is still here what, 12 years later? And still going strong. >> Uh yeah, just as mentioned a little while ago, I was going to bring up the systemd one because it was a good example of like a big, long, contentious, argumentative, you know, big process. And I think Fesco at the time did the right thing. We rejected it the first time it was submitted. We said, "This is great and all, and there's a lot of advantages, but the documentation is not there. And, you know, a lot of things are lacking. You need to address these things before we can actually land it in Flora." And they did. And they came back the next time, and they said, "Look, we added all this documentation. We did these things that you you said last time." And that was when we added it. And I think that was a really good success story of a contentious process that actually ended up giving us something that was actually a much better in the end. >> The only problem with that with that was the timing that it also matched the the genome 3.0 uh That is so having those both hit at the same time was a bit rough, but >> So, uh um something that didn't yet happen, but uh the the switch to uh a new Git Forge. I think that um even if it will not have been an actual change, but I think it will have a change for it. Okay. Um so, in a sense, we there was a previous attempt to switch to GitLab, right? We were pretty close to I mean, it was it it it even seemed inevitable at at one point to some people. And it was kind of rejected by the by Fesco and by the community. And now we have another attempt at at Forge I/O, and I think this is uh seems much better. I mean, I think that we have support in the community. Technologically, it seems much more reasonable. And I hope it will reinvigorate our development efforts for for packaging. The it gives us a a chance to do a lot of things better. >> So, for me, it's not necessarily any particular change. Like I the the whole change process and the fact that you are on FESCo uh board, it means that you're supposed to go through the deeply to the changes and understand them. So, that process itself, that's probably the most tangible part that I have from being being on there. And from the recent days uh or recent releases, it's probably the Anaconda changes. So, I personally haven't seen the Anaconda installer for like 10 years. That says you something about the stability of the NF upgrade. So, I I I took it to I I had a chance to see what the what it's coming in and it's amazing to see that we are progressing and we are not stuck in the same ways for years. So. >> Um I have a question and I don't want to accidentally phrase it in a contentious way, so grace and space. Um It's two parts though. The first part is by show of hands, how many of you have been a member of FESCo for three or more years? So, I view part of FESCo's role as shepherding the change and introduction of new technology and other pieces. At off the cuff, cuz you weren't prepared for this, how are you all thinking about making space for new people in FESCo, but the continuing contribution of those of us who are graying and have a lot of good resources and ideas? I'm kind of echoing what Jeff brought up earlier. >> So, every time we have elections, there honestly there are not a lot of nominations for the open FESCo seats. Um often times, it'll be the same exact people that either self-nominate or someone else on FESCo puts their name in. And I know Neil, I know you've you've said like, "Well, we should at least have a couple more people run." Um >> I dragged this guy in because >> And I wanted some new people in. >> Right. And I I don't know if if it's a matter of people not understanding um the eligibility or or if they can do it or if it's like a a long process. Maybe you know, we should probably um write up something that explains that. But I've thought that maybe to cycle through we should consider term limits uh just because that would force some people to to cycle through. >> but maybe like you can serve twice consecutively. >> Sure. Yeah. Right. Yeah. >> One thing that keeps me out of FESCo is it's a huge time commitment. >> Yeah. So that's the other thing is yeah is is people look like I'll I'll talk to people and say, "Hey, there's an you know, election coming up. Would you be interested in in running?" Well, what does it involve? And I'm like, "It's great. We have these weekly like unbounded meetings and they're >> minutes. >> And you also have to do a bunch of homework before the meeting and it's great, you know. And well, what do you get for it? Your name on a web page, you know, and it's so >> and brain clicks by the >> And there's yeah. So I don't know. Maybe we could we could sell it a bit better, but um I I do I I think that's a valid concern because I we should should be making new contributors aware that that they can run on FESCo. They can you know, if they have a voice, they have you know, they can do this um and yeah. >> Yeah. So this has been like so I actually personally only started running for FESCo once I had an idea of how the heck did I block time off for it. Um because this was something that used to come like for a long time I wanted to be part of it but like the long time frame and like the un- undefined knowledge of how it's supposed to work was difficult. Then I started sending my own changes and having to participate in FESCo meetings involuntarily and it and started getting a much better understanding of what that was supposed to be. And I've actually, you know, I I've done a fair bit of trying to encourage and mentor other people to be part of it. Like Fabio is actually like the first one I've done this, but I've done it with a couple of others. Like the one that's not here, Michelle, was another person that I like I kind of shepherd that person into becoming part of FESCo. And it's something that I enjoy doing is I like helping people like >> [snorts] >> become more engaged in the process and become part of it. And that's not necessarily to say that like I want people I want to be replaced, but like I would certainly like to have a lot of I I value broader perspectives, more perspectives on things because I think that helps make us better. It's part of the reason I'm involved in lots of Linux communities and not just Fedora's because I think being in a bubble screws you up. And so, not being in a bubble or at least puncturing the bubble a little bit every once in a while can give you a much greater understanding of things beyond, you know, what you perceive and what you directly see. So, I think it's very valuable for us to bring in more people. And I've even thought of like, what if we just added one more person and added another slot or maybe we shuffled the slots or something like that. There's a bunch of a bunch of things to do, but like I think the biggest problem is that it is very, very hard for people to conceptualize what kind of effort it takes to be on FESCo until they engage in some part of this process. So, you tend to see people come in after they've done a few change proposals and been engaged in the full cycle of the of the engineering process and then they feel more comfortable with the idea of being engaged with us. And frankly, that's a very small pool of people in Fedora. The vast majority of people who are packagers or technical people are not engaged at that level in Fedora. So, that's why you tend to see maybe the same people, but a very small subset of people. Like, this is also why I have gone out of my way to start doing more mentoring and other things. I've brought up like three SIGs with brand new contributors in the past year. And and this has been a part of the thing that I I try to do to try to like encourage more engaged and people that can be part of this process. >> Uh so, I would say I think it is a very valid concern, and I think we should be thinking about it. Uh another issue that plays into this though is that uh the elections for FESCo are very much like kind of a knowledge recognition type of thing. So, if you're a new person, even if you're interested, you have the time, maybe you're you have the ability to serve on the committee, you throw your name in the election ring, and then like the voters who are the technical people who've been around a while don't know your name, don't know what you do, and so they're like, "Oh, I don't know who that guy is, so I would just vote for the people I'd normally vote for." So, I think there's that aspect of it. Um I think we could do more about like maybe having some kind of here's [snorts] how you if you're interested in this sort of thing, here's how you learn more about it, you know. Here you can attend meetings, you can look at these changes, you can provide comments, you can actually, you know, step up and and provide even that without the voting aspect of it, you could do that. But then again, it's a thankless job that's, you know, a lot of time. So. >> Um yeah, I I I also agree that this is a problem, and I don't think that there is an easy solution. I like the idea of having to take a break every once in a while, like two terms and maybe a one to skip. But, there are other bodies that you can get involved in, in particular the working groups. I think that we it would be great if we had more people in the server and workstation working groups being more active and taking more of a role of driving some parts or the or the risk five group and and so on and so on. >> Um What I wanted to say is that while working being on FESCo and working on stuff, it might look intimidating at first, but you don't have to know everything when you start. That's No, you don't have to know anything basically. You I mean you you do learn on the job. That's part of part of what you do. You don't need to know everything when you when you run or when you when you start on FESCo. Uh I mean yes, it takes time to to read the mailing list posts. It takes time to follow the discussions about change proposals. Uh but you don't need to I mean you don't need to read the discussion for every change proposal. You can just say I am not comfortable enough with this topic to to vote on this. I know that that you guys are all uh very knowledgeable with that and I trust that you'll make the right decision. You can just say I didn't have enough time to spend on this. You do it. Uh you don't need to do everything all the time and that's helps when you're starting and it's kind of limits the uh the time that you need to spend on on it. And of of course over time you'll uh get more comfortable with more topics and with more uh parts of the process. Um For example, there's It It almost looks like new FESCo members are always a bit uh intimidated by running the their first meeting because we we rotate the the person who uh runs the meetings and that's always "Whoa, I'm I'm not sure if I can do this. It's my first time." You'll be fine. So, yeah. Yeah, it's uh the whole process is pretty well documented. And there's not much you can do wrong and even if something goes wrong, there's always uh time and a way to fix it, so. >> [laughter] [snorts] >> The last question, what a treat. So, um there's a there's I'm sure you've all heard of the Universal Blue community. Um in the last 6 months, there's I think almost 20,000 weekly users a day and there's um uh about 200 contributors, which is amazing. It's amazing to see Fedora used in this way. Um so, my question is, how does how has that new audience or group of contributors factored into your decision-making? >> Um I don't think it has right now. Um and because it generally, although this is now slowly changing, Universal Blue as a downstream has basically not engaged with Fedora as a upstream. Um this is something that um I've kind of reached out and started to try to change things. I know a couple of other people have. Um I expect to see some improvements on this front in the coming year. Um but I would say that a downstream that's not engaged with us as an upstream is a downstream that we kind of can't account for. Um because without engaging with us, we can't know anything. We We're not mind readers. And what they say publicly might not be what they actually mean to say to us from different point of views or different things like that. And so I mean, sure, it's great. And And they're obviously doing stuff. I'm personally a fan of Basalt because I feel like purposeful appliance experiences work very well with that technology. Uh and Basalt is a good example of it. A lot of the other stuff I've seen have been less good examples of it. But Basalt is, I think, a shining example of how you can leverage this stuff well and do something that actually makes sense with the tech. Um It It's It's a complicated situation, but like I think I think we'll see We'll see improvements on that front. And as Universal Blue becomes more engaged with us as Fedora upstream, I think we will naturally start seeing um their concerns integrated into the the overall decision-making process because when you're part of the Fedora community, then that sort of just naturally happens um over time. >> Neil, would Would another way to say that is be You'd like to see Universal Blue more like what Asahi is? >> Yes. Yes, more or less. Um Uh so Dusty was asking was like, "Do I want to see Universal Blue operate more or less like how Fedora Asahi Remix does, where we're very close to the project and we essentially engage uh and and coordinate uh very closely to support things even if we are doing things sort of side along or outside?" And the answer to that is yes, and then I think that that makes it much easier for us to be able to account for them. I think we do, you know, like for example, in Fedora KDE's SIG in the personal systems working group, we do a good job of accounting for Asahi stuff and bubbling that up into the other spaces because they're engaged with us through that avenue. We don't really have that in uh for for Basalt yet in particular. Um although uh Noal is here and one of the priorities that he and I have for being here at Flock is actually setting that up. And so that's something that we want to actively improve um over the next year. Uh we'll see if that propagates to the rest of Universal Blue, but I know that Basalt has specifically been interested in being more part of Fedora Upstream. So that is um I can't make them come to me, but if they want to come to me, then I'm happy to help them be part of uh be more engaged with Fedora. >> And you're willing to make some concessions then. >> I am willing to have discussions with them and we can figure out what to do there. Uh more than that I am not willing to promise. >> So in general I think that uh we should keep our downstreams close as much as possible and the more engagement we have, the better it's for both sides. I mean it is certainly more work for both sides, but then we can do changes faster and we can avoid uh changes happening in the upstream that downstream doesn't like and then has to deal with um yeah, so like also for for other things like uh RPM Ostree, we are only now integrating the development of those images with the upstream like core Fedora workflows and it's still not complete. And in in hindsight it I mean we should have done that much much earlier. >> I kind of wish we made that a requisite when they became an addition, but like it was I think that was my main problem when Fedora CoreOS became an addition was that they weren't made to become part of the Fedora engineering process and keeping them very separate has led to special levels of dysfunction that I don't think we wanted to actually have. Um, and so those are the kinds of mistakes I want to avoid with with stuff like this. Like even with Fedora Sahi Remix, like we try very very hard to minimize the amount of stuff we do actually outside of Fedora. Uh, because uh, it really messes up the coordination and the integration efforts that we we do. That's why, for example, the FEX change that enabled in Fedora KDE the ability to run x86 applications on ARM through emulation, particularly for gaming, uh, we did that in Fedora to make it work for Fedora Sahi Remix. Uh, and we made sure that there was a variant of Fedora that had it, that matched our flagship, and provided a consistent experience for that within Fedora as a project, because we wanted it to benefit both of us at the same time. That's the kind of thing that uh, Nolan and I are discussing about for Basalt in particular is figuring out how we can get those touch points in place. And it's not just Universal Blue, there's a couple of other ones that are that I've been that some of us have been reaching out to and and engaging with to kind of bring some more of those downstreams closer to upstream. Um, but we'll see how it goes, right? Like we can only try it out and test and see what happens. >> Okay, thanks a lot for answering the questions. And if you will have any other questions, you will find them around. Now, we will have a 30-minutes break and uh, for those of you that need a vegan or gluten-free food, you have them at the back close to the open door. Uh, so thanks a lot and see you in 30 minutes. >> [applause]