 Let's do this. We represent the four ninths of Fesco, so even we don't have quorum today. We're going to cancel, right? Normally, we would cancel the meeting, but let's try for a bit. My name is Byshek. I work on SystemD and I have been in Fesco for six years now, I think. Yeah, my name is Neil. I do lots of stuff in Fedora and other places and things like that. And I think I've been in Fesco, I think I first got in Fesco at the start of the pandemic, so I've only lived in pandemic era. I'm Kevin Finzi or Narek and I've been in Fesco since it was the Fedora Extras steering committee. Oh my gosh, that's a name I haven't heard in forever. And I am David Cantrell. I have been on Fesco, I guess also during the entirety of the pandemic. This is actually the first time we've met in person, so that's kind of interesting to think about. I've been in Fedora for a long time. I work on software. We do things. We've been around. So yeah, meet your Fesco the way these normally go is we just kind of open it up to questions. However technical you want to get, or non-technical, we can talk about anything really. I will check if there are any questions online, I guess that's probably a good idea. So one thing that we tried is moving the discussion of Fedora changes to discourse, discussion Fedora project org, and I think that the results were mixed. We started with some very tough ones, so we are overloaded by the number of comments. Personally, for me email is just more comfortable, easier to get around in, and more familiar, more efficient. But on the other hand, we had more comments from people, from new people and people from outside of the community or fringes of the community, which was well, challenging in some ways, but also good in other ways. So I don't think that it's, at least for myself, I cannot say that this move was clearly good or clearly bad. I can see it both ways. I hope that with other proposals, which are less contentious, we will have a smoother workflow and then maybe it will work better. And I don't know, that's how I view it. I was wondering how other people see it. My brain melted during that discussion. I have some thoughts on it. I'm always in favor of making it easier for people to provide constructive and valuable feedback and input into the thing that they're using and building upon and being invested in. Enabling more participation is always great. The flip side of it, though, has been this particular discussion wound up feeding itself into a very destructive frenzy. I think the easiest way I could describe it. It got amplified and re-amplified and fed on itself because it's the trade-off of how far you want to go and how much you want to have input from. I don't know if we've figured out a good balance for this with putting it into discussion FPL. My personal opinion about this is I have some reservations about continuing to do this, but I'm also willing to see how some of the others go before making a full judgment on it. I'm glad we're trying the experiment and seeing how that's going to work out and seeing what kind of participatory effects and what kind of quality of discussion we get. It gives us a good idea of whether this is something we want to continue down or not. I guess we'll see. My observation has been that we wanted a way to get more input on change proposals. That's the core item that we work by on Fesco. You've probably seen them before. There's a process. We discuss it. We vote on it. That's how changes get into Fedora. On the mailing list side, which I will say I'm more comfortable with that only because I've been doing this for a long time, the mailing list side, it felt like at least over the past couple of years, change proposals would only get comments by roughly the same five to ten people. I don't know if that's because they were not as visible or that people just felt like they were not welcome to comment on it or it was kind of a thing they couldn't participate in. So expanding that, getting that outreach through discourse has been good because it makes our discussion on Fesco easier because we have input from more of the community. What do people actually want to do? Is this something that people want? So just having more data points is useful. But I see the discourse side as having an opposite effect. So the people that were comfortable on the mailing list are now uncomfortable on discourse. So we can pick one set of people we want to hear from or the other and we can't get both, but the answer isn't to post it in both places. We need to come up with a better solution. I do think that when we tried the discourse method, we did not really do a good job of explaining what the change proposal process is to people who had largely ignored it. So I observed a lot of community members thinking that these were more of announcements of decisions that had been made as opposed to discussions of changes. So I think we could have done better at explaining what this was going to be and what we expected everyone to do. So that was, I think, kind of new for everyone. I don't know if you guys noticed that as well. Yeah, there was definitely a lot of people said this is a foregone conclusion. And I think there's a couple of reasons for that that at least I observe. It's like one of them was the way that changes have landed in Fedora over the last decade that I've been observing this is largely been uncontroversial, super easy. They go through, the feedback is discussed, and things are resolved before they get to us. So it starts looking like whenever they get to the FESCA level that they're quote unquote rubber stamped. But the reason that they get to the point when they reach us that we're all comfortable with this because we're also participating in these discussions and people are resolving our concerns way before we get to that first meeting. And so people have this conception of we rubber stamp things when we actually don't. And then on top of that, the way that the news reports on Fedora's changes process, like so if you look at some of the pharaonics and others, there is a very, very important reason, a very big reason why we now have this banner that says this is a proposal in the Wiki pages is because there was a number of incidents where volatile changes were being proposed that people assumed were going to just happen. Some of them didn't actually happen, but they didn't know that and they reported on it and misreported. And then there's this like view that a change proposal isn't in fact a proposal, but like the equivalent of like what a proprietary vendor does and says, hey, we've done this thing, you got to just deal with it, right? Like that's the, I think that's the two big parts of it. Yeah, I think there's some really good lessons learned from this discussion that we had on that controversial change. And I think that's one of the big outtakes from it is that people don't understand the process and we need some way to tell them this is a proposal, you're supposed to give feedback, it's not done yet, it's still under process. Also, I think there's a lot of associated things around that like people didn't realize, a lot of people thought with this particular proposal, oh, it's a team in Red Hat. So Red Hat proposes things and then people just approve them. Well, no, anybody can propose something. If you have something that you want to do and you're willing to do the work and you're willing to write it up and get it through the process, that's fine. Anyone can do it. But I think a lot of people didn't know the process and perhaps were pointed at the discussion from a context like, oh, here, you should say no to this and they just would go and say no and not actually read through the proposal. So I think there's lessons learned from it. I think I'm also on the mixed case. I think we got a lot more input from people on the outside in the community and that's great. I think expectations were bad. We learned some lessons. Hopefully those will feed into this and make it actually better. I think it's still worth doing. I think it's a good experiment and we don't have enough data points really yet. This is kind of a crazy outlier. I hope it's a crazy outlier. I don't want discussions to be like this all the time. How do we think the Nano Default Editor proposal would have gone? I think it would have actually gone the opposite of the mailing list. You bring that up and in all seriousness, I think if we had in theory-crafting land that we had the nano discussion on discourse rather than on the mailing list, it would have been completely the opposite way because the people that are on discourse are the complete different set of people than what we've been interacting with on the mailing list. A lot of them are either newbies or first timers or they're thin, they're first into Linux and their points of accessibility into the terminal and all this other stuff, they would have appreciated the change more than a lot of the people that have been old school have been battered by the old unixes and whatever and they've lived by the scars of their heads and vies. I think it would have actually gone the other way and it would have been contentious for a different reason. Because you'd have some of those old timers complaining that we just did something for, you know, I think we've actually had some of those complaints during the thing about like we're simplifying or making it like we're not making it less... Yes, we were making it too easy. And stuff like that. Oh yeah, that definitely comes up too often as people think because it was hard for them, we should keep it hard for everyone, like difficult to learn. I want everything to be easier than what I had. Yeah, I mean that's kind of what we want to do. It's a good point. Comments from the audience please. So we robbed people of the learning experience of how to get out of them. I mean that's a good point and you know people brought that up and you know, it's kind of funny all the points that came up specifically on the nano change proposal I don't use nano, I used Vem for like 25 years and then changed to Emacs and actually became way more productive but that doesn't matter. I mean the editor is everyone's choice, right? And you didn't just slip that in just because. Right, yeah, yeah. But I think in one conversation I brought up like you know guys like Gen2 which is you know if you really just have a lot of time to burn and you want to set up a Linux system you can't but their default editor I think was nano actually. Yeah it still is. So you know it's viewed as kind of a high tech you know end user sysadmin distro and it's using nano so you know whatever. And another counter point to this particular like you want to keep it hard so everybody learns the hard stuff is like I have skills for how to screw around with DOS systems like I started with MS DOS and I used DOS editor I screwed around with config.sys and autoexec.bat How many of y'all after have to touch one of those these days? I promise you almost none of you do the unless you're like doing retro stuff for the fun of it like I do sometimes. So like those kind of like you don't need to keep things to be hard to keep it fun and to keep people learning. You give them new interesting things to learn and grow from. And there's new hard things for them too also. Oh yeah the hard things don't ever completely go away. They just change. Oh he's right behind you. This thing is like nice to hear but I actually don't mind about either of them nano in whatever but I would love to hear your insight into the recent decision about DNF5. So that's the controversy so put it on the stage and I'm especially curious like yeah it happened to revert but why it was reverted in inrohide especially why not to foster in inrohide and continue testing development there. Yeah so I think at I said this multiple times I think that I'm very proud of the DNF team for like looking at this and deciding that it wasn't ready. You know most of the time people who invest so much time and energy and work into something and there's a deadline and they're not quite meeting the deadline they'll try and get it in anyway but I think they did a really smart thing and a really really good thing to decide to pull back from there. And I think the question as to whether leaving it on inrohide to get more testing I mean it's still there people can use it it's just not going to be default but we don't want rawhide to be used as a just a test bed where it's not actually intended to go into the next release we want it to be a integration point where people are actually testing the thing that will you know go to the next release. So I I think it's good to revert it there until it's ready to to actually go in. I don't know how much more really much more testing would go on there it's hard to say but there are a lot of the stuff like the API wasn't stable until fairly recently as well and so there's going to be a lot of stuff that's porting over to it but it still can be tested it's just not default so. Oh yeah I I'll add that the DNF team is the team that I work on as well and you know it was I guess it was disappointing but really the the correct decision it just the feedback in general on DNF 5 and the current state leading up to Fedora 39 there was there was too much that was unfinished in my opinion. I DNF is is one of those components in Fedora that we absolutely need to work and since we already have one that that is implemented to move to one that that loses core functionality that we have documented that we tell users they can rely on just it it just felt incomplete so it needs a little more runway to to sort of complete that and just this morning I was talking about test days implementing more DNF 5 test days I think we came up with three that we need to do but the Fesco ticket where we were talking about implementing the contingency plan to revert it there there were a lot of things that were pointed out there and to me I feel like that was a kind of a rare situation for us to get that much feedback which which to me shows that people were trying it but a lot of stuff just didn't work yet and it just you know I like like Kevin said the the DNF team just saying like yeah it's not ready we should we should pull it back and and even still just not just bouncing into the next release which is another common thing to like we need to rethink our approach here and maybe it won't be ready for for two releases yeah and as someone who's you know I have a connection with the DNF team as well because I've been a community contributor for almost eight years now in in the various you know RPM systems software management group projects the the DNF 5 work you know when we started when it started getting rolled out and people started like it was very very clear that the the use case prioritization there was a mismatch between what Fedora needed and what the community needed and what the team thought they needed to to be able to make it happen and we were encountering pain points and issues and the community was bringing them up actually fairly promptly and that was that was also unusual usually we don't get anything for until like the last minute and things were just you know and they were being very very responsive in addressing the concerns and working through them but it's just when you get a huge pile of them and there's just only so much work you can do at once you've got to qualify all that you got to make it work and and like David said it's the core of our system we have to make sure that it's actually solid to the point of like not breaking it like the one of the reasons we went from young to DNF was to massively increase the reliability of doing the core thing that we need the distribution to do which is manage software and we don't want to screw that up in this transition and so I'm really happy that we're taking a step back to take that next step forward Justin go if you remember during the the young to DNF switch you know that was actually rolled out it not not it wasn't the same state the DNF five is but it was a rolled out a little prematurely as well and there was core functionality of young that was now missing from DNF and that caused a lot of problems and we got over them it was fixed and you know DNF is great now but we don't want to repeat those mistakes exactly yeah that I was on the anaconda team at that that change point and one thing I remember is during that switch over we would we would have a bug report for young we would file a bug report that team would would fix it but fix it in DNF and not young so it was like we were starting to have the two drift apart and we just had eventually had to make that cut over and yeah we got we got past that but it was it was bumpy it was you know they wanted to say like look the time for DNF is now it is fundamentally different I remember one of the the big difficult things with young and DNF at that time was installation if you had young as the back end in anaconda you would get a different resolved set of packages to install versus DNF because there were different depth solvers and that it's like well okay I guess we're just going to have that now maybe and yeah so that's long since passed but it's it is important to remember that so that we don't end up in the same kind of situation one that I was disappointed that is not fully implemented yet as the system upgrade capability that we rely on now in DNF that's not in DNF 5 and I was like well I mean I use that you know like that's got to be there you know so little things like that you know we definitely need to get my question is so do we revert to stuff like do we have somewhere the list of things issues which needs to be solved and not just in DNF but with the integration with other tools Fedora review discover other stuff like which needs to be solved when Mach is done that's that's my project so which needs to be done so we track it and that surprised one year later again because I asked yeah I recommend I check what was the status of the other plugins as well not just copper plug in so it's tracking somewhere inside our GitHub like but it's not visible outside for the people who are not willing to dive into the bunch of issues etc. we have yes we have that information it's incomplete right now because it's mostly from the first DNF 5 test day that we did but it does have a lot of those results what what did not work what were we expecting bug reports were filed they've been prioritized in my view they've been prioritized differently than what Fedora was expecting so we're at a point now where we since we've reverted this in in rawhide we need to go back as the DNF team and look at all this and say okay this is how we need to prioritize this work and yeah so that information existed it's coming together so there was some additional information on that in the Fesco ticket to people were saying these things are blockers and then you know some of them weren't some of them are this is implemented or it's different or whatever but some of them definitely were like system upgrade is not there and you know things like that well and you mentioned Fedora review but also all the integration with Fedora infrastructure stuff like and like I did a lot of the early porting work for moving from young to DNF for all for a lot of the relinch scripts and things like that and I literally couldn't start figuring out how to port things from DNF 4 to 5 until like two weeks two or three weeks ago and that's really not enough lead time to be able to make sure everything works and the API wasn't stable until recently so right and it's not like I wasn't aware that they were working on it and thinking about it but like going through the effort of making all these changes especially as a volunteer and spending documentation and not having understanding of the expectations with the API interfaces and stuff like that's it's a real chore to go through all that stuff and like I'm not going to ask any volunteer to do all that work when they don't know what they're supposed to know and you know once we like that's that piece of information is something we kind of have started to get and I'm kind of and I'm hoping that that gets fleshed out more in the intervening months so you know giving that feedback from the API side because I know that the test days have given a lot of user feedback we haven't done a whole lot of producer feedback which is also important for being able to switch over to it because I don't want to repeat of where it took us five years before we could start using rich dependencies because nobody could figure out how to port like the Bodie and other stuff to use DNF instead like that was I want us to be able to move like that properly to everything that's still good because that before that we had like what ten years of speaking about it so I'm really proud that it actually happened yeah but that was also like the most painful porting projects so when the DNF 5 discussion in Fesco started we made an effort to try to build a list of requirements and this list was some list creator was very incomplete and I think it's kind of the same problem that appears in this kind of switches and I think it's I mean one lesson for me would be that we need to build this kind of list and building of such a list is hard because you need good insight into not just the thing that is changing but all the surrounding tools and processes and that's hard and I think it's particularly hard in the case of of Yam or DNF because there's just so many so many points which need to be touched and so many of the external tools are like dead or semi-dead somebody wrote them five years ago and they live in long scripts or somewhere else and as long as they work nobody will start them again so nobody knows and there's no clear I mean we have Federal Review and Obsolution Scripts and this and that and I mean half of those things have no clear owner, no ongoing maintenance and nobody will think about fixing them until we switch and then we realize that they're not working so if we could do this again we should probably try to figure out how to find about those things earlier I want to add to that yes I agree but on the general topic of requirements this comes up from time to time and to me Fesco should not be the body that is dictating hard requirements for projects like that I mean really when it comes down to DNF we refer to the change proposal owners the engineers who are working on that but generally speaking our job is to vet these changes and say okay well the requirement from our point of view is don't break things for users like so have you done that we need information to determine if you've really set things up that way and I think in this case the DNF case they're needed there was such a broad impact that that team needed help to really understand who all needed to be a requirement so in that respect it was a little unusual but you know really changes are changes and that might mean that requirements change for software so we shouldn't say you know in a change proposal this team wants to do something we shouldn't go in and say we don't change that because we like the old way you know I mean that's just not really what we're supposed to do another thing that actually that change proposals really do and I think do well is I agree with you that the team needs to kind of figure out what they're doing and propose something but like in this case DNF is so pervasive across the entire project that they probably very likely do not know all the things so once the change proposal is out there they come and say well you know my thing uses this and have you talked to me well we didn't even know you were using it so I think that the visibility has helped a lot there and this is where I say this is the change process working as designed because if you think about what a change is actually a proposal is about it's a description of an implementation of something that is going to affect the distribution and the community so the community responds to that provides feedback in kind and we as Fesco collate that feedback and turn it into something in bite size chunks that they can turn around and provide something actionable like we go through and we understand and like when it goes to a meeting we say like these are the things that the community highlighted to us that are important you know please can you find some way to address these issues so for making this acceptable and that's essentially what our job is at least the way that's how I view it and we're doing and the DNF changes and actually both changes we've talked about today are excellent examples of how we arbitrate those changes and make sure that you know we try to have the community's at heart when we try to make when we implement things in Fedora Linux I have command and I concur with you and disagree with David I don't know how that works I don't think Fesco is just about vetting stuff but like Foster and a lot of people think that Fesco has executive power and we know that no executive power you can't do anything I would love to know where this executive power comes from but I think you have huge power and that's the poking stuff and we actually seen that when Zbyshek started what's the status of DNF5 and that was the moment when this starts happening to move and that was just the poking poking about the other stuff pushing so I think we don't even have poking power we have mostly stopping power Fesco unfortunately can say no but it's very hard to force any kind of action maybe as individual members we can poke stuff but as a body we can only say not this cycle they can also just ignore us and do it anyway they can ignore you we mentioned here we are waiting till the DNF5 will become default and then the semi-dead projects will only fix the stuff and I think it can be benefit your body group to poke before it's going to happen please poke poke change it, change it please if they will ignore yeah that's the life it can change from semi-dead to dead project actually I think that's where change proposals can be proposed with more structure around them have deadlines within it we intend to land this change initially give us some data points that we can do that poking by but really stopping power is the only thing we have that's why we have the contingency plan requirement and too many change proposals will come in and say not applicable self-contained change it's like well maybe that's true but we still need a contingency plan we need the ability to back this up what do we do when everything breaks basically I've seen a few change proposals that had been before they even reached the mailing list Ben when he was doing the thing he would kick back ones that had the section completely empty you would be surprised how many of them don't have one at all before they get to the point that they get posted that's actually maybe at another event we should do a presentation or a workshop hack fest kind of thing on how to write a good change proposal we've all written some I help people when they have questions on how to put it together and it appears trivial but there's key information you need to think about and put in there although the hardest part of it is actually doing the work depending on the change proposal you can write the change proposal and then have someone else do the work that's great if you can get it to happen I mean one change proposal I did was literally including one extra package into a cons group so it was a one-line change but the change proposal document itself was like I think six, seven, eight pages long and it's just that also reminds me of it was one that I think was abandoned some years ago that was proposing there were some spec file macros the really complicated sort of the forge macros it was something related to that the change proposal was just so long and so detailed but whoever wrote it sort of abandoned it and I don't I'm glad that happened because if we had to discuss it and vote on it we would have had like a crazy long meeting one day and then never voted but yeah actually if you look at the wiki for change page incomplete which is the initial status there's a whole bunch of interesting things out there you look at a proposal and you're like that's actually kind of interesting but it was somebody who started doing it and for whatever reason didn't have the time to complete it or whatever and that's actually interesting to look through back through the history there and sometimes you look at one of those things and you're like wow that's a really good idea to revive that a couple of the changes I did were actually me reading through the old features list when they were all called features way back in the day there's some old abandoned ones there and it's like oh this is interesting let's see if we can pick it back up now that things have changed enough to make it better like it's also if you're thinking of doing something cool or interesting or you want to do something cool and interesting and you don't know what you might want to do you could go look at the old graveyard of changes and see if there's something that catches your eye and maybe you want to spruce it up and try it I'm going to ask please don't revive the Fedora K FreeBSD no don't do that that came up at some point I don't know if it still exists on the wiki but yeah someone there was a joke proposal several years ago we hope it was a joke proposal I hope it's a joke proposal to add the K FreeBSD and then like add the resulting infrastructure to be able to dual test everything on Linux and BSD and it's like no somebody did that somebody actually did do that as a derivative distribution I don't ever want to see it again Justin wait wait I can't hear you sorry sorry man I'll start building that kernel in copra we can get started now and if you do that can you also add Fedora Darwin kernel too oh yeah I know there's a lot of people that would love Fedora Darwin I don't like having hardware working so you know that seems like an ideal kernel actually IBM did some experimental kernels too we should maybe throw in I believe they use Linux drivers to make it easier like the K13 kernel and things like that oh that's perfect yeah then we're good to go let's go yeah so joke or not we need it on the recording and also nothing a very good deleted from the wiki so I'm sure it's still there so we have a question in the chat what all things Fesco is thinking to do to explain how change proposals work and how Fesco works to the larger crowd and we have been touching on this in some aspects but maybe so there were a few things that actually that Matthew came up with that I think are pretty good especially for the discussion side there's actually a video out there that describes the change process and having a link to that for people who like video explanations of things you know right there in the top also some more explanatory stuff you know in the change proposal itself like maybe going to the process or a short summary of what the process is or something like that I think could help but yeah it's difficult to provide that context with somebody who's just coming into new to the project it doesn't know what's going on and we've added the disclaimer and stuff like that to the top but it's difficult to convey like the whole process but yeah do we have a section in the documentation about writing a change proposal I think so yes we could probably expand on that maybe do some blog posts just raise awareness as well I think it's a topic that we should probably be continually revisiting just because people come and go like it's one thing to do a one-off you know and that's good but the audience changes so yeah the video is a good idea and you know just increasing the marketing and communication the hard things to do the other thing that's really interesting and I thought of this earlier and then it kind of faded from my mind and now we're talking about this again so it came back as the way people talk about it is if there's a fedora team that does stuff I would love to know what this fedora team is because I've never seen them aren't we all a team here I guess I don't know but like it's really important the really important thing to convey is that a change proposal can be done by anyone who is involved in the fedora project at all right and there's no like team of people that can make them and do the things and whatever it's just any member of the community who is interested enough to drive an improvement to the project I mean we've seen the changes process be abused for things other than the actually changing things in the distribution so clearly it has gone a little bit further than that but like it's intended for technical changes but we've used it for project changes we've used it for culture changes we've used it for a lot of things anybody who's interested in driving change in the project is the method that the whole community is able to synchronize on and understand what's going on and get consensus on so I think it's one of those things that it's hard to do from the inside because we have been leaving this process for so long that we don't see how it looks for people from the outside and maybe some newcomer should take on this job and figure out how to explain it to people who haven't been familiar with it for a long time well we all actually stop talking that happens every once in a while anyone have questions more any in the chat nope how are we doing in time we can okay okay so some fling so if you would have executive power oh no what do you would change in fedora whoa so I have one thing that I was recently looking at fail to build tickets in my packages and other packages and there were a few there was a package that was preventing 50 other packages from building and I start looking at it and I see oh actually somebody filed a poor request to fix this package a year ago and it's been hanging there in this ever since and I don't know if we could have a way to just have poor requests out to apply after a week if nobody protests then I would like to see that happen are you sure you want that because like that will be careful what you do kind of a wish and also I mean it's so we have the package dashboard which makes it easy to see all the poor requests but it's also apparently very very easy to miss poor requests you get a notification but I also get maybe a hundred other notifications every day so and maybe there should be some mechanism to escalate this that's one thing I have like it's on a lighter note if we add executive power I would like to bring back the Fedora release naming yes the reason I say that is that and I'm not saying it has to be implemented but what I liked about that is it was a participation point for everyone in the community regardless of their level of contribution or their technical skill everyone could vote on a name and then we had like each time we made a release it felt like we were this community around that release and we would have that branding now we did make it extremely difficult the process and stuff like that sure I get that maybe we could fix it I liked the release naming thing that we would do it's always in the back of my mind is that I wish we kept the code name stuff because it was a fun point like one of the earliest entry points for me was helping pick the name for one of the names that was on the voting role for Fedora 12 it was a long, long time ago and like I I think that that is literally one of the easiest entry points that someone could have to have some ownership of what we make as a project yeah exactly if you've just joined we're about to do a release and you get to vote on this name and you see it written up in articles and online and stuff like hey I had a hand in that it was just an ongoing entry point for anyone to really join maybe we should bring it back for that alone wouldn't that be easier if we do the discourse where you can vote just with plus one I don't think it was the voting that was the difficulty the problem was of course as it often gets down to lawyers yeah well Spott can share some back story with that but it doesn't look like you really want to right now but so maybe maybe we can get out of that business now but I mean just from a community participation standpoint I think it was really useful that said of the release names that we did have what do you guys think was the best name I'm gonna say Zod Shroudinger's cat Shroudinger's cat is mine as well I mean we also tested the UTF support yeah yeah I'm gonna go with that although werewolf was a close second because all the kinds of combinatorial like the community artwork around it was phenomenal that's true I do like the Shroudinger's cat one because it did create the release blocker on an apostrophe yeah so the act of participating in choosing the name actually led to an actual technical bug find you know which was neat and well sometimes have the feeling that it's too hard to do things in federal like that there are things that should happen and in general people agree that they should happen but they don't happen because well stuff is slow and so I I mean there's many places where I think we should as a community keep in mind that just delaying things indefinitely is not a good outcome and so if I had executive power I would just use this power to generally make things happen if possible I'm gonna go with that be careful what you wish for for that one again because that can go very very badly I have another one on executive power I'm gonna assume that we have an infinite budget oh yes let's go with infinite budget on the condition so I would like to hold a flock and fund everyone in fedora to come to it regardless of distance and all that stuff so that with the infinite budget now with the leftover money what would you guys do with the leftover money of an infinite budget next generation coji with being able to reverse depth tracking all rebuilding because then I don't need to hear of proven package request simply because they were the unfortunate souls of a library but they can't actually upgrade anymore because they can't fix everything I would like that kind of grunt work to just go away yeah I was gonna say I could spend an infinite budget on infrastructure there are so many things if I could hire 500 people to redo this thing in a sane way and fix the tooling make things so easy for packages it would be amazing yeah what do you see is the future of diskit in light of things like paggers current maintenance status and people moving things to get lab and things like packet leading more people to not really treat diskit as the canonical source for spec files anymore all right we have time for everyone I will keep my statements on this short I promise having pulling away from the canonicity of diskit is a recipe for disaster I have been in distributions where so some of you may or may not be aware that I actually am involved in much more than fedora over the years have been involved in over a dozen different Linux distributions who have done a variety of different ways of shipping software one of them you know from a lot of those experiences one of the things I personally feel is a colossal mistake is orphaning your agency of the method in which you ship software and so one of the things that we have to be really careful about with stuff like packet and what we are calling source get others called merge source trees or get package trees or whatever you want to call it is we cannot orphan our agency of what we ship because we are still ultimately responsible for it the distribution get or diskit is our packaging get repost that maintain our agency for that the canonicity of that hosting it inside central fedora infrastructure is how we preserve the integrity of our systems projects like Debian which do not have that requirement have to work around that problem by doing things like their reproducible builds efforts which give say that for packages that are going into Debian we need to try to find a way that you can do a reproduction of it from the output artifacts to recreate the output from the inputs produced by the output artifacts to create the same outputs again we have much more sophisticated ways of being able to verify builds than they do because of these other guarantees that we have to be frank we don't talk about like why we have made a lot of those early decisions and what benefits they offer the packer versus whatever thing the maintenance status of packer is in flux because we have got new contributors coming in who are actively working on the project earlier late last year I was able to with the fedora infrastructure folks finally get the CI infrastructure working again which means I can start accepting contributions and that has led to a slow revitalization of the project in a way that we are actually heading towards a new major version where we are doing a lot of clean up killing out a lot of cruft code there is a lot of weird experiments that we have done that are not needed so we will see how that goes we have 3 minutes left 2 minutes left I will be actually very brief also I think we need to have another discussion about this I know people maybe don't want to hear that oh no another discussion but I think things have changed and I think this shouldn't be a top down debate we shouldn't say oh we are moving to GitLab that is what we are doing here is our options we could stay with Peg error revitalize it we could go to something like Fostodon or Gidea those sort of products now that are out there and have the possibility of federated repos we could we could do GitLab we could do GitLab in different ways we could run our own GitLab we could let them run it GitLab for us etc etc all these things are a choice that our community should have in front of it and look at all the facts and figure out and maybe it goes to a decision from Fesco or something like that or maybe there are constraints around costs or whatever that way into it also but I think we probably need to have that discussion again but I think that we are going to GitLab is a conclusion from several years ago that we should stick with that's my take I just want to add one thing because you mentioned packet as well as where Diskit lives so I separate sort of thinking about the workflow of package maintenance and where source lives and that sort of stuff that is a they're related problems with different what I would like to see is a discussion and decision in Fedora about the direction that we do so packet like if a project is going to adopt packet building from upstream then I don't want to also see work happening in Diskit like I don't want to see patches and PRs there and have it be bidirectional because that's really not like we should we should define what the flow looks like from upstream to downstream integration in Fedora and I think that's important because it gets confusing with some projects so I think it needs to be handled the other way like I would also say that Diskit is the canonical place and you are welcome to use any workflow you want to put things there and I think packet is an option that is certainly growing in its usefulness but you it must take into account the proven package workflow and request from the community and they just must be integrated into I mean like any changes that you do must take into account that things happening in Diskit independently keep in mind that if you like let's say we go with the idea of like if you're using packet then you don't have people don't do it in Diskit that means for example proven packages are completely cut out that also means that other community contributors if they are not members of the upstream project that's using packet they can't get changes in that also means if we do modernizations or infrastructure changes they can't do anything either it's actually like an extremely painful problem if we block people from being able to work in Diskit so I'm not advocating blocking I'm saying that Fedora needs to define what those workflows are because right now that's too ambiguous and anything can happen and what I see is stuff gets lost it's actually not that ambiguous the packaging guidelines pretty clearly say that Diskit is the canonical source for spec files and patches and whatever but some people think of all these reasons why they don't have to follow that rule or whatever it is and that kind of goes to communication and marketing and making sure everyone understands and is on board with what that says Speaking with my packet head on the problem is more like not as Neil mentioned not allowing people who has the right to do something in Fedora Diskit not allowing them to upstream but like when people use packet or other tools and maintain the spec file somewhere else and it's just technical way where to put the stuff so Koji has something to build and if people submit the patches or prerequisites there it may hang there for weeks slash months slash years we don't impact it to make that for us to happen so it's more about letting people note that the maintenance actually do the stuff somewhere else and if they want to submit some contribution they should probably submit it somewhere else and it may speed up things so for me the canonical point of view like I don't know what is canonical thing in this context so I think that this was a major design problem in packet I mean it was I know it's sorry but things will not work well this way and we'll dig a hole we have 8,000 projects and with 8,000 upstreams we'll dig 8,000 holes for ourselves to fall into I don't know that it's necessarily a hole I mean I understand the problem but for example Anaconda I don't know if they use packet they do release upstream and then they maintain the spec file there and just sync it to disk it but there are occasions where a compose will fail and Adam will figure out what the problem is and he'll talk to the Anaconda folks he'll be like here's this problem I'll file a bug, I'll file a pull request but I'm fixing it in disk it right now and building a new Anaconda so we can have it compose and that's fine because when the next thing comes along and it over writes there's already a pull request because he knows that in the next version that they release so I think it's to your point it's more of a expectation thing if you don't know that and you come along and you're like oh I'm gonna file a pull request or the kernel as Justin will no doubt point out it's the same way it's if you're filing a pull request there or changing something there that's great but you should realize where you need to make the change that's what I'm talking about is that core issue there so we do actually have in the page when you went to the page with linked kernel arc saying this is where it's maintained but we still allowed pull request I did actually turn off pull request because they were just being ignored but I don't think that getting rid of disk it as much as I know a lot of people in Red Hat would say source get should be the canonical source this is where we're working but I think disk it serves a good purpose there in that I do I overwrite disk it now I check the diff every time so if somebody's done something I'll at least see it and hopefully they've put in a merge request and the source get but having disk it there does mean somebody can go fix it without waiting for everything else yeah exactly and so that does serve that purpose but you also what we just all said the expectation that you're gonna fix it there but I know it's an upstream project that's gonna feed back in so I understand how that works and I'm not gonna have that change lost but right in the interim I need to fix it now so the other problem is that we have not defined an expectation of upstream projects that wind up doing this because here's the deal when you're integrating into Fedora and you're doing this stuff ultimately the Fedora contributor has to win in a conversation where something needs to be done to fix something and if that is not happening if there's no responsiveness in the upstream project there's no responsiveness downstream the Fedora disk it something has to win, something has to give and right now what happens is if somebody has gone to go packity, source getty, whatever and someone submits a change upstream like they're doing it and no one responds this is an even worse situation than we have now because there is no agency we have lost a way to realize a solution because we have deferred our agency to someone else who doesn't have to care about what we're doing and that is the crux of the problem I have with upstream upstream packaging but what you just said is that you describe this as a last resort no I'm saying that if you're following that workflow you consider this as a last resort it has to exist as one it has to exist but I think we are slightly heading to a situation where we have to clear clearly say what is canonical source and deferred from the last resort or something to do about it and probably with packaging we will probably get off in near future and we will see where we'll head it as the important thing is that if somebody is going to use upstream project packaging in fedora and then ship it into fedora they also need to understand that there's an expectation that they've got to respond to fedora needs or otherwise we're going to have to do something right well I think the point there is that things can change like say you have a project and you're maintaining it upstream and you're just putting that into fedora through diskit and everything's great and rosy and whatever and then maybe somebody takes over the upstream project but you're still maintaining the downstream thing and they make some change and they're non responsive at that point you may want to break that relationship and you may want to say okay now we're just going to maintain this here here is the canonical source because the upstream is doing things that I don't understand or not being responsive so I think there needs to be a way to tell people what the canonical source is and it can change it could be that it's not tomorrow that it was today I think it's a big problem if we're saying that diskit isn't the canonical source anymore I mean one from the agency aspect and for the ability for other people to collaborate on the distribution together but also for the contributor experience like if one package is using git lab and one package is using code board one is using git that free desktop dot whatever it just creates a very bad experience for contributors and we kind of lose that collaborative aspect and that anyone can go in and leave a review and I don't think that we should be you know trying to communicate to people that the canonical source is somewhere else I feel very strongly that the canonical source should be diskit yeah so this is you know when I look at the contribution experiences between Debian and Fedora this is the core difference because Debian doesn't have a canonical source requirement which means that we they do not have a singular path to contribution for any package it could be anyway actually you're not even required to have a VCS for Debian packages you can just upload things and they will do that and then you're just going to have to figure out how if you need to do something how it's going to get done and that's not something I want to have in Fedora at all on the other hand who has more packages Debian or Fedora we're that does how many of them are alive it's Debian and I think it's make hard thing contributing to other packages but on the other hand like this situation make easier other contributors taking care about new packages because it's more easier for them so weighing the problems and the number of packages is less meaningful than it perhaps used to be because now we have Rust and Go and a lot of that stuff is just sort of auto-generated but you know yeah also like you have to think about the quality and the usefulness and the liveliness of those packages there are a lot of packages in Debian that do not have a functioning upstream or development or whatever they're just carried forward forever and they don't fail out of the distribution because of things like oh they don't compile because they don't do those kinds of things like we do where we fail out packages for not compiling year after year the way we handle our distribution tilts towards active maintenance which means we will always have less packages than some other distributions that don't have that preference and I personally would rather have more high quality packages than less low quality packages because Fedora is you know a collection of high quality packages that has guidelines and standards not just a kitchen sink of every single possible open source project in existence so we are 11 minutes past the initially planned end of life of this session so I think that I mean this is a topic we could continue for another hour so let's just wrap it up now and thank you all for coming thank you guys