Dealing with Dormant Packages: Ensuring Debian’s High Standards

And happy birthday day. Liberty, egality, fraternity. And as we say in Debian, freedom, equality, and endless mailing list threats. But seriously, seriously, these um values line up with pretty well with the free software is all about. We have the freedom to use and improve software. We have equal access for all and we have a global community that mostly works together. So let's celebrate both revolutions, the French one and the digital one. Yeah, as I said this is above. Please everyone comes come close here because people need to run around with a microphone. uh please interrupt me at any time and I really need your help because as you might have seen in the schedule I have two buffs in a row and I was thinking can I manage to talk about two things that are pretty important to me and also to Debian as I think but I think we can do it together and I really trust you that that you can help me because I got a lot of help in the uh the preparation sprints and what I'm presenting now is heavily based on on the sprint we did on Friday but I will give you a short introduction why I'm why I at all thought about these dormant packages um last year in my bits from DPL I announced um back of the Okay. And I had the intention to attract newcomers with this uh thing and doing some practical demonstration for people who have only a limited time frame. And I can tell you regarding attracting newcomers, it was a total failure. The newcomers didn't expose themselves whatever. But the outcome is um uh we fixed not I fixes on we fixed lot of QA issues. We reported potentially uh maintainers with potentially miss missing in actions. We fixed lots of packages that were not touched by their maintainers for five years. We asked for removal of package with a either low popularity contest which were off or possibly unneeded which nobody cared about and all the packages we touched were migrated to Saza with the idea well I consider Saza a good idea in any case but if I want to demonstrate to newcomers step by step what I'm doing this is most probably the best thing I can do and with this intent initial intention in mind we hopefully did the right thing. The first question >> does that mean packages are maintained better? >> No I can >> no >> because you said you take all that packages to the other on the other hand you you have few packages from the other to to to fix. Yes, I could also uh touch packages from za but our selection criteria which I will present right now are the package is not yet on saza. So now now are the selection criteria. The selection criteria is the package has an open buck which is not teched won't fix or pending. It has a standards version which is lower than four which means eight or nine or so years old. I don't know the when this exactly the standards version was it was not uploaded the last five years by the maintainer of the package. There might be NMUS or something like this and the package is not yet available on Sala. Um it might be in some other version control system. It might be somehow remaining on on Elliot and not uploaded again or somewhere else. And I usually present five or select five candidates by from UD with these four criteria and I put them these four candidates on a web page. Um my slides are online. If you do a web search for Andrea's till talks, you find a table and you find this uh PDF easily and then you can click on all the underlined things which are links. Right? So the problem is we have uh quite some package with lots of bugs even very very simple ones which are unanswered. I consider a simple um bug when the homepage is missing or wrong. We had quite a number of uh bug reports wrong homepage. Right. This is a simple bug. I think it should be fixed because if some user was sitting down find report bug blah blah blah missing homepage we should acknowledge that the user has spent some work in the package and this work should be rewarded by doing an update upload. So we had a lots of packages with wrong wrong homepage or not up to date watch file or missing watch file. We had outdated packaging standards. Well, this is the selection criterion. We had outdided copyright information or format. I try to create uh to move to the depth five format for every package I'm touching. It might be that I'm lazy in a few cases, but usually if I upload a package, it's dep five format. And we found package which I call with uh with no good reason on Zaza not on Zaza because we have maintainer we said no no no my package should not be on Zaza. This is a very good reason to not move the package to Zaza. I'm not aware of other good reason to not move the package to the other because if the maintainer says yes I don't care whatever or the maintainer is not available I think it's it's a good reason to move to the other this is what we are doing so there is no pressure and maintainers who don't like it we ask before we do something and then we can talk about and I found issues that were not addressed for several years. So this problem is in my opinion caused by the following reason. We had once invented the ownership based maintenance which means I'm the maintainer of the package. This is my package. And um it this made perfectly sense historical historically in the first five years because we had a couple of experts dealing with a couple of packages, right? And we have no not really technical means enforcing this. What we agreed upon, it's a social rule. So I could upload any package. I'm not doing it right and I think usually it's not done but Debian has evolved over 30 years now we have uh two to uh two to the^ five years now they 20 32 years old right and um things have enhanced for sure we have team maintenance which has quite an open maintenance model and the whole problem was not really clear to me because I'm exclusively working in teams inde I have a lot of packages but all the teams have the policy well the person who detects the problem fixes the problem uploads the package [snorts] team upload ready done this is um my vision what we could probably do generally in Debian I come back later to this but this is somehow uh Um yeah, we we have usually the freedom to do some good things, but the social rule somehow says no, no, you should not do this. Sometimes it's for good reasons. And we talk about this. And another reason is we are all all volunteers. Volunteers do a lot of good stuff for some time, but none of the volunteers has subscribed. Oh, I will tell my friends that I'm going away. Right? Volunteers might get children, whatever, get busy with other things and find no time to say, "Oh, I'm away." So, we need to find out who is away. And we have no good means for this. So, the conclusions of this buck of the day is I didn't met really solid stats, but say if I contact the maintainer, I get no response from 80% of the maintainers. I fix homepages and watch files about 80% of the packages I migrated to dep five for about 80%. Only 80% of the package we touch are really worth keeping in Debian. So we try to remove some but sometimes this is even easier to fix the package than to find reasons to remove and blah and so we tend to keep but we also remove packages and in fact 80% of the things we types are really easy and we also have about 80% of the packages have one smell there's a link to smell it's done by Luca Newsbomb what means smelly um yeah it's defined there so I do want to go into this detail. So the problem we have is we have no efficient procedures to modernize packages and only a few volunteers are work on these due to a lack of non frustrating procedures right we have procedures but all of these procedures are currently frustrating for the person who wants to do it and so nobody's doing it and we have sometimes disagreement of uh some or who are quite vocal oh you are permitted to touch and and a lot of people agree with me that we should do something but they this is a silent agreement I I don't know I want to go into the philosophical details here what do we have we have non-maintain uploads [snorts] or NMU and formally only dedicated changes we have permitted but just by talking about what we are doing we recently relaxed the rules to yeah you even can fix some package smells except of moving to salt this is too invasive but this does not really solve the problem of an inactive maintainer but you have another NMU to the package but the maintainer is there on its not there we don't know and we have the um package salvaging procedure with a intent to salvage bugs we find this means we Find a new team which might be also the Debian team or whatever. Working on all smells is fine. Moving it to salsa is fine because you you take over the the responsibility for the package. That means a new uploader for the package is required. That means I have more than thousand package on my desk which I really if anybody wants to take one package of mine please do it. please right and I have too many packages but yeah I can add myself as uploader then we have another uploader and it's it's it ends up in my mailbox if but it makes no sense if I or the other members of the salvage team add more and more and more on their their desk. So this is also not really the procedure we want to follow. So we try to find uh more teams with volunteers to maintain the packages and um we also have a special team on sala. I hope everybody is aware of it. Uh the previous leader Jonathan Carter made a lot of noise about it. We have formerly we had collab maintain on Aliot. Now we have the Debian team. This is in principle the team where you can do team uploads and you can care for a package. Please do so. Yeah. And we also I've also found a lot of packages which remained in color uh main onot according to their version control system or the VCS fields. Some of them were even on ZA but not uploaded since then. Some of some of them I picked from the archive, migrated from SVN to git. So there's a lot of stuff to do and um yeah, but it's also not really funny work to do. Well, when when then yeah may I ask questions you please? >> Yeah. Um my question is could you please go back to to Yeah. So uh you say that um some packages are many packages are on Debian Salsa team but as far as I understand not all of them are marked as team maintained. So it means that uh if you see the package which is already on salsa DBN group it is not automatically team maintained. Um maybe we should formulate it somehow that if the package in DB and SARSA team please do uploads because uh for me it's not quite clear how we so you should check first of all whether team maintain it or not and then to check where it's hosted. So I think it's very good >> intention I understand perfectly the question as I said Jonathan Carter made a lot of noises this is the case everything in Debian is team maintained we have please look up the wiki we have some wiki page stating that this is team maintained I'm not sure if everybody is aware that this is the case but let's assume that everything in the Debian team is team maintained for the moment Right? And if somebody is not happy about this, this package can be moved to somewhere. But let's assume for now and do something. So we have the uh missing an action process which is um which is a man manual process to find maintainers which are missing an action and I reported more than 30 of them. I see the package in this list of the five packages. See this maintainer. Oh, is he active? I check contributors.net is and then I report if it seems that this person is not active anymore. The MIA team is actively working on improving this process. There will be some announcement. So uh what we can do now I have some suggestion two suggestion I start with a even more invasive one to do some to spread some ideas what we could do in general and if the um in my opinion thinking of the the team structure make Davian a team but in principle when I was running for DPL I tried to do the very same as I did in this smaller subgroup DBN made D is is not important for Dian right it's it's not a big thing but we found a structure for the team which is in my opinion totally functional and the proof that this is totally functional is that I said if I get elected from for DPL I will do not do any team work anymore And the the the most important message for me from all this running at DPL the team is functional and working. Thanks to Eten and whoever is working in the team. So this kept on working. Yes. Kind of an applause. Thank you. And I really want to bring also Debian in a state that if someone is leaving Debian it's automatically others will work on the stuff that is left behind. So with this idea I started to apply the same measures I did in Dian made also in Debian. I well formally we had not these procedures. I sometimes did things which are not really in line with you don't touch my package. I moved every single package which is uh which is in the field of medicine and biology to the Debian made team and sometimes with the maintain I was not asking then I did it anyway this 15 years ago but yeah it worked and this idea is is one of my ideas why we should try to do the same in in Debian and so I want to somehow tear down down the barriers between packages and people uh all these are links to the two threats in the mailing list. So if you download the PDF then you see this because um our current pol policy is efficiently restricting the freedom of a DD who is not maintain or mentioned as maintain or upload and I don't think this is a good thing. So we are seeking mechanism for shared or a collective diffused responsibility. So if a package is in a bad shape, the whole Debian project should be held held responsible. Either it gets fixed somehow or it gets uh removed by someone. So and I really really want to make you some better suggestions. Um the um the schedule has a link to the pet. This is the same link. So if you have some ideas, open the pet, write it down. The pet is not empty because we worked on it on Friday, but just add your ideas. Questions so far? Yeah, >> there is a question uh from from IRC. What about salvaging packages into the QA team or salvaging team as well as MIA procedure? >> Yes. Well, uh I came to this sure uh salvaging into QA team is is not the right word because the salvage procedure is defined as I find a new uploader and QA team is a package without an uploader. Right? So um I have I come later to this that we have the intent to off procedure which I try to uh suggest. So I said I'm writing an email to the former maintainer. [snorts] I want to offan your package and I wait 21 days and if I don't get any answer I I'm fixing the bugs and so on upload to delayed 10 or 15. We should agree to about this. It is not a not a decided procedure. I tried some what I called experiments which I will blame. No you are too fast. We have not agreed. Yes, we have not agreed about this and I'm not proud about doing some things which we are have not agreed about this but I think in general it helps Debian it packages which are of so low relevance of so low popcorn and finally it could be reverted if necessary right so intent to offen is the process to set the QA team as a maintainer, no uploaders and do a QA upload and we do it as well and we put it in the Debian team so anybody can pick it up from there. So is this answering? Yeah, I hope I hope this answering. >> Yeah. >> Yeah. Um there is one more question or I would say is more comment. Um >> I'll just read it. I'm not sure that Salsa Debian group being quite that open as actually documented. we only have it's a bit like a collab maintainment if there is a real uh consensus on this we need to document it better so I agree with that so I I also support this idea but I think we need to have one a single source of truth where it's documented maybe it's policy and just to maybe start um discussion about changing it changing it and uh to to make this suggestion there >> could someone do me a favor and put this in the pet because this is above we want to do new things we want to do and some kind of a to-do list in the pet is perfectly welcome right so my idea to to define the procedure to um uh to that we can say okay every package is free for everybody but there are package with very very good reasons to not to touch right I I would not touch the kernel or lipy package for for Right? We should be clear about this and then we can agree about some file the name I'm not good in inventing names but I suggest as a working thing file Dian don't touch my package if this file exists don't touch the package right >> please please talk in in the mic I think it's so hard hardly named because there might be package which people might be happy that people contribute to, but they want to have a second pair of eyes onto it because there there might be trivia changes which will break the package. >> Yeah. Yeah. Yeah. to talk to me. >> Yeah. Yeah. Yeah. So, >> yeah, we we we talked about similar things on on Friday. Um, we can use this file to document [snorts] like don't touch it before asking me or well, in general, I really really believe that this is a very good idea if you want to touch the package to contact the maintainer in advance. [snorts] Well, we mostly talking here about packages where the maintainer is in a way absent that he is not answering for three weeks or longer. We time span I just suggest three weeks. So if I write the maintainer an email I've done this and this is this okay for you and I get no answer and this file doesn't exist. [snorts] So yeah, this is we we really like to do something. Yes. Here's a question. Can can you get the mic? work. >> Um I think in general it's a good idea but I really think we need some sort of mechanism that works as a canary in the sense that if you put it there it should disappear after a year automatic automatically >> because otherwise everyone will just put it there and we have the same problem. This file should include a timestamp and this time stamp if it is five years old then yeah and we should define these rules clearly right it's perfectly right so it I'm really happy that you are repeating the things we we just were talking about because it makes sense right just talk about everything there's another um remark >> a bit a bit a followup to previous question and uh another issue. So basically one thing is uh the biggest problem at least for me to touching not my packages is that there is not uh always obvious workflow of packages. Sometimes GBP sometimes it's only Debian yeah exactly only Debian stuff and so on. So it's >> it sometimes it makes more time to check what it how to properly build package and >> and and upload this correctly uh then to apply those changes and related to that uh from the other side I've uh had the cases that some some people uploaded new version of packages but for example did not push correctly everything to G. for example only Debian branch and not orar or something like this. Yeah. Well, these are actually details, right? We we need to talk about details, but yes, with for the workflow, maybe you people are sneaking in my slides and I don't know. Yeah, but uh we are not talking about G workflows here now because it goes too complex. We have two dimensions, right? I agree this is a complex topic and it's important topic but it distracts us from the point. So we have some refinements found in the uh in the sprint and we need to agree upon the time frame when refreshing the statement right if the file is uh five years old I think it's clear if it's one year old we well this is these are details [snorts] um it's also a question um if the people say I do not want to upload to refresh this information and we can agree okay if it's in salsa the maintainer refresh in salsa that do not touch but on the other hand this requires that the package is maintained in salsa right so if the package is not in salsa you need to upload if it's in sala we can agree upon things and for sure we should inform the maintainer I'm not propagating that someone should upload something without informing the maintainer. The thing we should discuss is how long should we wait? Um Andreas, there is a comment on either part or I would say a couple of sentences. I will just summarize it. The question is uh whether we should agree that the package which is not being uploaded in one release should be should at least become one upload per release. It doesn't matter who is doing it. So I think it's details but uh this is details. I tried really hard once I was in a mamm to upload once per release but on the other hand we have packages that really don't need touching if there are really no bugs and it's architecture all package which does not profit from new compiler version. So we we also need the people to do the work right. we cannot set a requirement and then we have nobody who fulfills the requirement. So I would not I would not attach this question to this specific requirement. There's another question. >> So my suggestion um regarding one upload per release would be um to change the reason. So some packages don't need uploads but some page would benefit of getting a new build. Um so if the package is reproducible then we could do archive rebuilds from time to time and check if a new rebuild of the package would change. So which means for example we change a compiler flag with security flag and that would change the outcome then that would be triggered to say okay we should have another upload of that package to pick up changes in the environment or the compiler and not just do an upload because we want to do an upload. >> Are there really that many packages in Debian that have no changes need no uploads in a threeyear span? I mean how many how many pieces of software >> we don't know we don't know but as I said setting this requirement means somebody needs to do the work if you volunteer to rebuild every package great do it right so um other suggestion where we we want to replace is we have a low NMU wiki list and we should just don't use it and use this is not My suggestion because Dwell would be not a good list but we can use similar to the QA team um somehow find some active uploader or we use a collab maintained a well mailing list which receives all the messages back reports for packages that have no real maintainer. Um this would reduce responsibility of uploaders. These are all links to the to opinions on the mailing list. Please click on it if you have the PDF. There were also some implementation details like putting it not in don't touch my package but make readme.source source somehow machine readable and it could contain maybe even in control file something like don't touch feel free to update your m welcome something like this other suggestions other methods you see it's it's very open for discuss the thing opinions are really welcome I have no clear vision yet about how we implement this but I think it's important that we implement it And u you should always document the reason for discouraging others from uploading. Maybe the build process for this package requires a lot of experience and handholding. These could be documented and then yeah we don't touch it or changes to this package must be coordinated with other packages some libraries right so if you think I should update lip make sure that you don't break anything. Right? So this is not I I mean this is not a good example. I intentionally take this bad example to think to explain that we do not want this. We want to do lip something without any dependencies. This is what we want in in the the packages package pool I'm talking about. Yeah. So and there are different reasons that could be good reasons to not touch the package. Certainly what I'm suggesting here will finally lead or it has heavy consequences on our social agreement. So we certainly will require a GR. So we first need to find some consensus what we really want. It's nothing it is nothing that will happen in my DPL term. Right? I'm talking about the vision. It's not that we start tomorrow with this. For the moment, I'm just collecting feedback, more suggestions. [snorts] And any volunteers here in the room who want to work on this, please raise your hand. One volunteer. Yeah. Well, volunteers can write their names into the pet and then we talk about this. Well, we have tomorrow I have my bits from DPL. Wednesday is uh uh the the uh day tour, the day trip and but we have three further days to discuss things and if you find a group of people discussing things this would be cool parties uh other parties pretty full now for this talk. So you get a lot of feedback here. I will not read everything but I think uh your talk is good is is doing a good progress and good activity. >> Yeah. Thank you. So this is for the uh more aggressive approach. We have less invasive [snorts] things. >> So you have one more question. >> Yeah. Yeah. Sure. Sure. Questions are everything I've written here. You can read it but questions are interesting. While talking about long-term plans, um, are you considering automatic uploads for reproducible packages? Good. Yeah. Nice. >> Okay. But these are probably normal NMUs as they are done currently for rep reproducible packages. It's not really doing more things than necessary on on this packages, right? So what I specifically mean is that the changes you're performing are manual changes per package. Yes. Right. Yeah. Yeah. Fixing the homepage is is probably something you can't do automatically. >> True. But some of the standards changes some of the can done like >> yeah this standards and deper compat which also might break the build right because of the edge missing something needs to be changed also. Then if you can do it automatically go for it from here. So we always want to send our intention to the maintainers and we always upload delayed. So the whole process from I start contacting the maintainer to finally uploaded packages at least one month. We can agree about other things and um we also send uh an email when we upload to delay to the maintainer and to the open box sending them pending. This is this is always important if we do any procedure and so I tried in the intention to NMU. Well, I said NMU has in had some specific rules and I wanted to go beyond these rules and wanted to int tell the intention otherwise I can do a normal in NMU and um some this is the result of some uh uh uh response I got. The response is linked there and the the receiving end the maintainer said oh he understand I want to improve the state of long neglected packages this name is not good we I have a better suggest suggestion and it it is slightly expanding the NMU process for instance move move to salsa is not okay but I want to expand this and um I just want to handle more intrusive changes [snorts] and he this this maner and others but he confirmed it explicitly said I was just offering a bigger oneoff help to the maintainer I do not want to maintain the package but the maintainer has left the package for 10 15 years and he said I should do this ah this Andrea said done it great so this this kind of response was it I did not always resp get this response But we have a couple of people with exactly this response and this was told here. So we thought about intent to NMO is not good. We say intent to orphan. Well, this is actually taking the the package from the shoulders of the maintainer. All fanning is the package is QA a meant and we should think about if you want to have this procedure telling the maintainer we will or offend your package which is probably very necessary for a lot of packages. So the then it in includes investigation whether maintainer remains active or or welcomes oneoff help otherwise we do this QA upload with a time span warning and to delay it. So we are here for more ideas. I'm basically through my slides right [snorts] in time. There are more ideas. Yeah this the slides are here. Oh it's not good to see it. One issue I've run into in the Rust team is what happens when a team member disappears or loses interest or whatever. The current orphaning process doesn't seem to have any way to document that this package is still maintaining minimal background maintenance from the team, but it doesn't have a proper maintainer at the moment. >> Yeah. Okay. Well, what I'm not catching by my my Sentinel is the M R team packages have are in salsa. They are maintained by a team. If they have no bugs, I is not ringing a bell and I hope hope really hope that the Rust team has a standard version bigger than four. So I'm not talking about these packages and the Rust team is a team what that needs to decide what we are doing with this packages. If a maintainer goes away they the team needs to implement their means to to to deal with this package. Is this answering the question? >> Not really. Okay, then you should probably go to into detail later after I don't know the rough rust team. I'm I'm in in in Pearl team. I'm Python team, Java team, other science team. There is very easy when the if the maintainer goes away, we or the uploader the maintainer is always the team in in all teams I know. And if the uploader goes away, then we replace the uploader or add another uploader. This is this is a usual team workflow and I really really really hope that's not very different in the Rust team. I don't know the team >> that certainly can happen in the Rust team but you get this situation where the MIA team is telling us this guy's gone away. >> Yeah. >> And yet you don't have anyone who wants to put their name on it. And currently those packages are just getting left. >> Care for my newcomers for the Rust team who who will care. >> Is this what we do? >> Maybe. I think what he's aiming at is the dev cargo conf workflow where everything is in one git repository mixed up by different maintainers and all them being in uploaders and with and if one dis one disappears no one because it's one git repository and not various ones >> in in in rust there's only one repository >> the the most of the git uh git caros are in one repository. >> So, um it's not that easily distinguish >> like in the Huskll team, right? >> I don't know. Uh >> but uh what I wanted to say is actually I forgot what I was say. >> Um I forgot. Sorry. Okay. So anyway, we have time left or not. Shoot your task master >> Lucas. >> Uh yes. uh two comments. The first one is about removal of packages. I think we need to remember that what we are trying to do is build the best possible Linux distribution for our users and sometimes a low popcorn uh package that is using completely outdated packaging is still useful to our users. still better for our users to have access to some software even if the software step is outdated rather than build it from source and maybe they will try the package discover it's outdated and install it from source because they need the latest version but that's still useful to our users so I would be very careful about removing packages I think we really need to ask ourselves what is the value of this package in Debian are there alternatives that are strictly better >> before removing packages is based on criterias that are mainly relevant to us uh as a distri for our users. >> Sorry, sorry. >> Are you ready? I I have an answer for this. What do you want to continue? Well, the thing is well looking at the photos I took from this image I took 20 or so and my wife said only this is good. Remove the others. So a [snorts] collection in principle gets better if you remove things but in Debian is probably different um for certain reasons and also in the Dian mid we have zero popcorn packages but other packages which have no zero popcorn will be enhanced by this. So we we know our users, we try to care for them, but we should make sure that the effort to manage these packages if even the maintainer doesn't care anymore is beable. So we do it by a case by case basis to remove it. And as I said before, sometimes removal is costs more effort than just fixing it and doing it. But but I want to have the permission to to fix it without any constraint without people oh you are not allowed to right >> uh okay I I didn't know you were finished but you finished >> so my second point is about uh ownership I think that some amount of ownership is useful it's useful for pe to have people that feel responsible about something >> even if they are not interested anymore in fixing it the fact that you committed to do something means that maybe you will do it >> feeling a bit forced but uh >> uh so I would be very careful as well with removing with changing this sub balance that we have in Debian. So I agree that we could we could go further about NMUs. For example, >> you in your slide about the delay Q you say that you want you should we should ask you should notify the maintainer first not askify first and then wait and then upload. >> I think that if we had a way to uh upload to delay queue and then easily remove that upload from the queue or even let the maintainer remove that upload for from the queue we could notify and upload at the same time. That's a simple way to >> Yes. Yes. Yes. I'm totally we made failure in this process. We had two or three where the changes were emer packages in this worked on these packages and we made one or two mistakes. >> Yeah. People who are doing things are making mistakes. I'm not proud about it, but it can be reverted and we should. >> Yeah, but I mean if I if I'm able to email the maintainer saying I fixed this, I upload it to the DQ, feel free to cancel the upload for any reason even without explaining it to me. >> That's much uh easier because it's just a fire and forget process and don't need to come back to >> it. It happened that I've removed something from the new queue. Yeah, but yeah really I think uh the value ownership is valuable teams the current structure in teams is valuable because I mean in the Ruby team we care about stuff that was packaged at some point even if we have no interest as current interest in that package uh and uh yeah so >> I absolutely agree very careful with that and >> we need to find out if this maintainership is not existing anymore And this is the problem. We have no means. We can't send some some uh picture postcard to the maintainer at home and are you there? Can you answer whatever if it's not answering the email? I don't know. >> Any more question? I remembered what I wanted to say, you know, of the first place on my last when I last had the mic and you have to be very careful to um if you if you if you do an intent to offen it easily can happen that you just put the burden on someone else some else group which then again. So uh you need to have some commitment to keep the package uh living or just directly remove it. >> Often is means often and it is >> yes but in the end it may may just linger again in the QA team. >> Uh >> yeah yeah yeah. So, and the second second one is you have to be careful about popcorn because uh >> there might be >> misleading I'm totally aware >> which has no popcorn but is still used because it just is a middle dependency or whatever. So, >> I have zero popcorn packages on my desk. I know this and I'm proud to maintain them properly. >> Okay, thank you very much. We are running out of time. Uh we have one more minute. So the last very very small question not comment question >> question um regarding maintainership uh I often feel like we're debating debating whether it's useful and one aspect I found useful there is that maintainers tend to be in a position to say no no no to changes then they feel are out of scope and and that way they establish vision this is something I feel we are bad at collectively when we touch other people's packages because we are including just changes because they seem good. Uh how can we actually get better at estab using this maintainer centric vision and being able to say no to things in a way that drawing these maintainer benefits but still maintaining packages collectively. It may be a stretch to answer this now. >> Yeah, it's it's too short. By the way, thank you for Hammood. Helm is responsible for about 20% of the bugs we fix because he is also fighting this FT fight to cross build from with all patches and this is also kind of an easy bug from F. Thank you for doing this work. >> Okay, I have to interrupt the discussion. I'm very glad that it was it is really active discussion. We have some comments on other part but uh it's more technical. You can uh definitely read. I ask you to use other part to document everything and use the time till the end of the week to discuss this uh proposal and to make some things happen. Thanks a lot. Thanks Andreas for your very >> Don't forget to add your volunteer volunteer to discuss this. >> Don't forget. >> So thank you all and please greet Andreas one more time. [applause] Thank you.