 is actually a buff, it is a discussion session for those of you who are not familiar with how it works in DevCon for these sessions. So I just have a couple of introductory slides on an experience of mine that I did in doing some campaigning for doing LC bugs fixing, and then there will be an open discussion on some specific topics. So this initiative of mine that I've been doing for several months, I called it RCBW for release-critical bugs of the weeks. And the idea was basically to fix an LC bug, which is a release-critical bug, more or less every day, and to actually do an NMU, which means that you fix an LC bug not only in your packages, but also in packages of other people, and to actually do some announcement of the activity, and in particular to do that once per week in the hope to encourage other people to do the same. So before going to the detail, just some credits. So the origin of this is not mine. It's from Stena Gunnason, which in the release cycle, I'm not even sure if it was Lenny. Maybe it was even Edge. Started doing that. And every day, it fixed one LC bug and blog post about that, about how I did that. And E2 tried to actually have other people doing the same. And also I would like to thank all the people that actually joined the initiative and started doing the same in the hope of having more and more people working on the same task. So my motivations to actually have that initiative is not the most intuitive one. So in particular, I didn't hope to fix as many LC bugs as possible in the hope to release a squeeze like after a few months. That was not the main goal. Rather, the goal was to try to have some more collaborative way of fixing LC bugs, and in particular of having actually Debian release happening. So for quite some time in Debian, we have a couple of myths, which I believe are counterproductive to the way we do releases. In particular, we have believed for a long time that NMUs are bad, so that if you do NMU of a package of someone else, that someone else can feel that you are entering in his ground, or you're doing something you should have done, or this kind of stuff. And that in general, NMUs are not welcome. So you should really think twice before actually doing them. So I was trying to see if those two myths were really true, or if they were just myths. So my underlying assumption for doing that is that I think that the way we currently release, and the way in which we have a lot of people in distribution who just care about their own packages, I think it doesn't scale. So we can't keep on growing and having lots and lots more packages in the distribution and imagine that just the release team will care about fixing all their C bugs that simply cannot work for much longer. So I thought that we need a cultural shift, and I thought that trying to do something like this could have helped in verifying whether we are ready to have this kind of cultural shift. So some details on the actual initiative. So it went on for 26 weeks, I believe, starting in September last year. I tried to have one of these critical bug fixed per day on the average and a bit less than that. I made about 180 NMUs, and I'm not claiming for sure that it was the hard bug to fix. So we were quite far away from the release phrase. So I probably fixed the easy one, but still RC. And I was really surprised by the feedback on maintainers. In particular, I got no single complaint from any one of the guy who got NMU. So I got no harsh mail saying, hey, what did you do with my package? Why you did the pin or anything like that? Nothing. I got a couple of overrides, meaning I did an NMU to fix an RC bug. I delayed NMU in particular, like two days or five days or seven days later. And the maintainer actually did a proper upload to override my NMU, fixing the bug nevertheless. So even if it was not, I think, really polite to do that without even getting back to me, nevertheless, the bug got fixed. And I got lots and lots of thank you messages. So people happy about having their packages NMUed having their bugs fixed by other and actually looking forward to collaborate with the guy who actually did the NMU. About having other people doing the same, about 10 people starting doing the same, and started posting about that. And they are still going on, even if I've stopped doing that. So I'm very happy about the result. In particular, I think that the myths you should not do NMUs has been dispelled, at least in my opinion and for me. And I think that all of this would have been quite pointless without communication, because the goal was really to have other doing the same. So how did I communicate about that? So a web page with motivations. And that's the URL where you can find it. In that page, I put the motivation for doing that. So stuff like what I've been telling you now, and also stuff like checking whether scratching your C-bugs is something which is sustainable in the long run. And I think it is, because many C-bugs are actually just packaging bugs that, in theory, everyone can see what they should be able to fix. A web page, I also put the NMU workflow that I followed, best practices for doing NMUs, and then point us to documentation like the wonderful bugs crushing primer by Steve Langasek, documentation, and all this kind of stuff. Then once per week, I blogged on Planet with a brief summary of the bug fixed, with pointers to that so that people can actually check the BTS and maybe point out mistakes in the fixes or this kind of stuff. And also point us to other people that during the week joined the initiative. That's pretty much it. So this is my experience. So the point of this blog for me is to actually share these kind of experiences. So I would like to hear experiences of other doing the same, in particular, which kind of feedback they got from the people which received the NMU. And there are a lot of other interesting topics that I think it's worth discussing here, like the point of actually advertising this kind of campaigning. Is it something which is really useful or it is just an annoying spam that gets on Planet and people have to just scroll down and pass to the next post? Something more substantial, is the goal of having more collaboration in how we release something which Debian would like to pursue or not? Do you think that in the future we will have strong package ownership and only maintenance will be able to work on their own packages? Or rather, do we think that should be something very more collaborative? If it is the case, how can we motivate people to do that? Should we, for instance, in doing the NM process tell to people that they should look out for our C-bugs and other packages and do NMUs? How should we communicate about this kind of stuff? What about the current NMU roles? So we have some very precise roles for doing NMUs right now. We can find in developer reference, five, 11, one, blah, blah, blah, which tells you which kind of delayed queue you should use to fix a specific kind of bug with respect to how old it is and other parameters. Do we need some NMU equivalent for removing packages? Because when you do LC bug fixing, you have quite some bugs which just denote that a package should be removed from the archive. And with that, we really don't have a process which is like NMUs. So there is also always some kind of uncertainty. Should I ask for the package removal even if I'm not a maintainer and this kind of stuff? And all in all, the question is, if you have done NMUs, do you think that having the maintainer feed was a feature or a bug? I mean, do we really think that having a maintainer associated with its package is something that helps the quality of the NMU or not? So I'll just pass the mic. There are a couple of microphones that we can use to start sharing experience of this. And I ask all of you to help in taking notes. And you can do that using Gobi. So just a second, okay. That's better this way probably. Just trying to see if we can fit. So there is a document, Gobi-debian net, which is called the C10 bug LC bugs where we can take the notes of this bug. And ideally, we should post them to Debian project if some substantial proposal comes out of this bug. So to you, you have the experience to share. I should what? I'm not connected? Okay. Now I can change the network, so maybe I think when I change my connection, go ahead in the meantime, please. So I did a number of NMUs or sponsored a number of NMUs with a contributor named Geri Alto. And the feedback was mostly positive. I think very similar to yours. Number of the packages that we NMU though, really the maintainer field, the maintainer wasn't there. Okay. And so we would always file an intent to NMU and then we would upload to a delayed queue so that if the maintainer just happened to wake up, maybe they didn't respond to the first email because we were not knowing them, but maybe they would. And then, but then the feedback that I got, and this is what I have to talk about, is how we change that not all NMUs are equivalent. NMUing an active developers package is very different from NMUing someone who hasn't done an upload in three years. So that's, I guess that's like, just throw that out because the feedback I got was, hey, you're violating NMU policy. And there was a brief discussion about that. So I guess an interesting question related to this is how you define whether a maintainer is active or not. So how can you anticipate whether the feedback will be good or not? Have you found some roles to do that, or something like that? No. I think that's a good open question. I mean, I think according to policy, I should have been going through the Debian QA group to determine whether or not a maintainer was active, but if you look at a package and it's using Dev Helper 3 or 4, the assumption in my mind was that that we were doing more common good by simply moving. And so the other thing we did is in addition to fixing the bugs, we would try to freshen the packaging because when the packaging gets that old, I think it's essentially unmaintainable, at least in a collaborative sense. Yeah, the problem is that with NMU, we have the practice of minimizing the changes. So usually you are not actually, it's not recommended to change the packaging. Right, Michael, Mark. Hi, well, I think his point in front of that, he disagrees with that recommendation. Where are you? Okay. Oh, hi, yeah. I didn't catch your name, but I think I understood that. If you're NMU-ing some of our old package with old packaging, you're going to have to do a lot of work. I guess it's a trade-off. On one hand, if you freshen the packaging, you could introduce new bugs. On the other hand, if you don't freshen the packaging, like maybe the new version of Dev Helper actually support policy better now or maybe it'll be easier for people to maintain. So you might be creating bugs, you might be closing them. It's kind of iffy as to if that policy is great. Well, okay, just a comment on that. I mean, so DevDiff is a fantastic tool and it's very easy to verify that you are not introducing packaging issues. So we tried to take great care. I guess, so my name's Tony, Team Ansel, or those who don't know me, and which I think is almost everyone. If I could interject here. One of the things, you do run across packages like this that are not maintained. One of the most important things is to identify these maintainers who are not maintaining their packages and start the MIA process and or consider whether this package needs to be packaged in Debian at all. There's nothing worse than, I mean, letting a package struggle along by QA uploads or NMU uploads. For example, a package that hasn't been uploaded in three years is a great candidate for QA upload. That doesn't, I mean, you may need, you need to communicate and give the manager a chance to respond, but that's not something that's being well maintained. In most cases, I mean, there are exceptions. There's some packages that just don't need to be uploaded that often. In general, if there's a bug and it hasn't been uploaded for three years, then it needs to be QA'd or the maintainer needs to be MIA'd. Hi, I'm Mark Shuddlewith. So first, I would absolutely, I think this is brilliant. I think that one of the most dangerous memes is this idea of exclusive control or exclusive say. It causes all sorts of, it causes not only problems with a specific package, but then all sorts of other social problems as well. And this is a very good exercise, I think, in showing that collaboration can work very well. On your provocation, though, I would say that something we've learned, I think, to our regret in Ubuntu is that if you make it opaque as to who a good point of contact is, you lose a lot of potential opportunities for collaboration. So we have a practice, which I don't really like as a practice, of making just the Ubuntu developers as the main, marking the Ubuntu developer team as the maintainer of anything in main or MOTU as the maintainer of anything in universe. And often seen cases where somebody wants to climb in and work with someone or work on a package, and they just, that obfuscates who they could actually most productively deal with. So what I would recommend is that you have a very quick and sort of automated foreback mechanism, where if it's clear, especially if it's clear in a sort of back robotic, you can't argue with the script kind of way, that someone isn't responding as a maintainer, that you then make that clear in the package within the maintainer field. But alternatively, you give people the opportunity to stand up and say, look, I'm willing to be the go-to person on this package. Well, addressing that and the provocation again, I think we're a little bit spoiled in the Debian Pearl team by having very, very active Debian developers who upload bug fixes very quickly. So the package is in good shape. There tend to be lots of them done. And the collaborative team model really allows anybody, a complete newbie to contribute right away really quickly. So a single maintainer, I'll stand on a limb and say, I think it could be a bug. Team mainorship, I think is really the only thing in Debian that's gonna scale to the 25,000 plus packages we have. I think teams are working in other places. I think Debian Med, for example, is a good example. So maybe if we explore that model a little bit more, that might help us scale. I think in fact that the problem, so I completely agree with you that the maintenance is the way to go. I think the problem is actually spotting the corner cases because while I agree that we have a lot of individual maintainers who are very active and respond to bugs quickly, it is not always the case. And in particular, when people retire, we not always have the guarantee that they actually, or from the packages, becomes difficult to understand whether, I mean, if you look from the outside, you really know a way to understanding whether if a package from its metadata is maintained by an active person or not. You can do some statistics, you go in the bug tracking system, you will look at last time the maintainer replied to, but it's really, really difficult. So I think most of these problems are actually related to trying to identify that corner cases and work around them. Wait for the mic. Hi, my name is Jaroslav Kalchinka and my question is, I wonder how many packages in your system are out running any mute versions at the moment? Oh, that's an interesting question. So we have a couple of tools to actually have easily a list of orphan packages of LC buggy packages. I don't know if we have a quick way to, well, okay, we can just do some graph. Yeah, if someone wants, I would like to keep the questions here. So if someone would like to do that, it's an interesting experiment actually. I would like to know who actually uses this low threshold NMU page. Is it good, do people go there before doing an NMU or just user? Just a brief description, just a few words on what it is. So when we, I think when we started to have some popular, when we started to make popular team maintenance in Debian, at some point in the same spirit, someone created this wiki page on wiki.debian.org which is called low threshold NMU and which is a page when you can and list yourself to declare, okay, I'm fine with NMU, my package, I'm fine if other people NMU my packages, please do that, I don't need any delayed queue, just go ahead. So in the beginning it was really a good idea and I think that the communication importance in showing that a lot of people are in that page. But I posed this question here because I think that nowadays this is completely useless. So I've never looked into that page to actually check if the guy whose package NMU is in the list or not. I just used the regular rules because it's just simpler. If the guy is really in that page and he's really happy about people having, about people NMU packages can just reply to my notification of a delayed upload and telling me just go ahead and do a non-delayed upload. Go ahead. You're saying? Yeah, raise your hand if you ever looked at this page before doing an NMU. More than I expected. Yeah, because I've had NMUs on my packages and I'm on the list, but people always delay them in my experience. Here, regarding the NMU equivalent for package removals, I'm not sure it needs additional process. The request of QA option often covers the same sort of case where a removal package would apply when there's not somebody maintaining it. Yeah, the problem is that the QA team in Debian is not really a formal entity. So you just join the mailing list, Debian QA, and we say that everyone in Debian is QA. So even if we have the error of QA, blah, blah, thingy, people which have never worked with QA usually do not feel entitled to do that. So they rather maybe drop a message to Debian QA asking, can I do that? People on QA expect him to just add. He expects people from QA to reply. So we have some kind of impasse. And I mean, the point of NMU is that anyone, any single Debian developer can really be bold and just go ahead and fix a problem. With the request of QA things, I think there's an additional step which somehow I think with a process like that can be simplified. Christian? I wanted to answer to Gordon's concern concern about low threshold NMU. You probably know I'm Christian Perrier. I'm doing a lot of NMUs for completely non-RC stuff, some localization stuff. So I did a lot of NMUs and I never used the low threshold NMU list for various reasons. I'm pretty sure that it is outdated. I also work offline, so I don't have access to it. And finally, I think that direct interaction is quite good with NMUs. And I think it is pretty much useless. I would prefer seeing in a package, something saying, okay, you can NMU this package with a low threshold, no need to delay, et cetera, et cetera, a control field or something. I think it would be much more interesting. Yeah, something I think that Debut can recognize and saying, look, you're doing a delayed NMU, you can really just go ahead and do that stuff. That's an interesting idea. Oh, by the way, answer to my question. So from 4,000 packages, which are on my system, I have 240, so it's 5%, not too high. And what's, which distribution is that? I mean, it's stable testing. Oh, it's mixed. Close to unstable, somewhere in the middle. Maybe, okay. And so it makes 5%, not too high, and half of them is 0.1, so they're just first stage of NMU. So it makes it to 5% of this first stage and the rest is a little bit further, which is, I don't know, someone treats it maybe as a good or bad sign. So in general, we have packages which are properly packaged and just 5%, it's about, so just a little portion of the packages which are NMU'd and most of them are probably will be handled soon. Okay, thanks. In thought here. In your experience, when you did that, the RC bug fixing, how did you end up package managed by teams? I mean, I have some people who are doing upload NMU and didn't update the SVN or the Git repository. So how did you do that? Okay, so basically the underlying point is how NMU's relates with the version control system, team maintenance, and this kind of stuff. So formally, according to our rules, version control system for package maintenance simply does not exist. I mean, in NMU's, you just upload to the archive because in Debian, the only thing, I mean, the only official thing we have is the archive. So the versioning is the archive. In my experience, I simply didn't care about version control system. I just went ahead and uploaded the archive, of course, posting the diff and blah, blah, blah, with the assumption that if there is some proper version control system, then it would be easy for the maintainer to just take my diff and commit it as it is. But that's a good point. Do we need some specific rules for an NMUing version package which are version control maintain? And that's post-garden. I would like to have them, but because if I had an NMU and it's not in my version control system, it's somehow annoys me. And if the NMU is like half a year ago, I tend to forget to integrate it. Okay, just a comment about views. One issue, I think another question is, if you NMU, are you being responsible for bug reports for the package? If so, for how long? And two, is there any way we can automate that? So I did the NMU that caused another issue, and I just wasn't aware because I'd done so many NMUs. Someone got with me and let me know what was my responsibility. That was easy, but since the BTS didn't notify me, the bug would have been picked quicker. So just a brief reply to that before using. So the best practice that I've seen on that is one followed by Tolymer and I've just noticed that for each NMU he does, he subscribes to the, I think to the bug that he fixed. I'm not sure if he subscribed to the old package, the BTS, but you can do both. So you can subscribe to the individual bugs. That's a bit of a challenge because we have a challenge response via email and Don will shoot me probably for this comment. And, but you can also subscribe to bug reporting all together to that package. So Justin first and then. Just about the script in Dev Scripts for BTS subscribes that allows to subscribe for amounts to a given package. All right, thanks. Just coming back to the VCS question. So I maintain most of my packages in Git on Elliot and while it's trivial to integrate an NMU diff in the version control system, the problem is I'm not entirely sure that the package that was uploaded. So if I rebuild from Git after the package is applied, I would get an identical package. So for me, I would prefer that the NMU are close to Elliot directly and then I know that the patch is there correctly. The uploaded sources are from the Git tree and so on. But anyway, it's trivial to apply for Git at least the NMU diffs. Lukas? Most of the control systems, it's pretty trivial to say like what Git import to DSC, which will import the source package from the archive. So really, I don't think it's that difficult to import, is it? No, it's not. It's just then. We have a workflow, right? For me, I consider packages that are maintained out of any VCS like that. I tried, for example, to look at some bugs, but maybe if I have access to VCS, I wonder maybe this is already thing in the VCS is just not yet pushed. But if all I see for a package is the sources, then I cannot check that. So for me, I would rather favor in general migration towards VCS maintained packages because then I think even the NMUs are easier, both in creating NMUs and integrating them later. There was Lukas first, I guess. I think that in the general, really good for developing really complex processes with 10 steps. And I really like the current NMU process which is still quite simple. And if we need to check a VCS, if we make it mandatory to check a VCS before doing an NMU, then it means that less people will do NMUs because it will be harder. And don't think that we should make this process complex. It still is the responsibility of the maintainer to commit the changes to the VCS. And I think that there are some teams who would describe the fact that NMUs commit to VCS. So you would need to have a list of teams that accepted it, a team of lists that don't want it. And then it will be an advance. Just a brief comment on that. I completely agree. What is interesting in having more liberal commit access right, I think it's for bugs which are not as serious as RCE. I mean, small, stupid thing. I mean, a type in a package description or stuff like that. So it would be really great if anyone can commit to the VCS of other team. And by the way, shameless plug, you can do that on Alio. You can just ask the admin of Alio to set access control lists on your repositories so that any Debian developer can commit to that. So we used to have that from the Debian OCaml team for when we were on SVN. I'm not sure if we supported that now that we're on Git. I frankly think we have never got a commit from anyone else. But for instance, I have an experience with Grape Debian Control, the Grape DCTRL Suite. So there, they have a procedure in which any Debian developer can push to Git as long as the commit is signed by a key, which is in Debian key. So that's interesting too. And I use that, for instance, and it's pretty interesting. It seems to me that it would be useful as proposed by various people if we had a whole field for this. As to go with the control field for NMU thresholds, you already have control fields for version control, and it should be fairly easy to put together a tool that combines those to make it very easy for people to cooperate with version control systems if they want to do an NMU. Yeah, but I think the point of Lucas is still valid. You shouldn't make that a requirement to do an NMU. So I mean, that would be nice. And so that if you want to be extra kind with the maintainer, you also follow his advice on how to be kind with the VCS. But I think it should be a requirement because of the way we'll get even less NMU, and I think the goal is having more NMU. Another complication with automatically connecting to the VCS is that often a VCS server will have some additional code that has not been uploaded, which then raises the question of whether that should be included when you do the NMU, which is currently against problems. True. Yeah, I agree with both of you that we shouldn't make the process more complicated. But I think we could do with at least encouraging committing to the VCS if the maintainer wants it, for me at least. But I think the problem is also that sometimes NMU also create branches, like in the history of the package, if you have some small fixes. I wouldn't mind if I just fix the typo and thought it's not worth an upload if the NMU just uploads this as well. So if you want to go that way, the first thing you need, it's really for all VCS, we use for package maintenance in Debian to be committable by NEDD. And I've tried pushing for that like three, four years ago. But I think the initiative didn't really go far. So that's the first step. Before being able to say you should also commit, we should have really VCS where anyone can commit. And we are not there. One problem with this could be that there's kind of no way to advertise that you have a VCS that others can commit to. Wait for the mic. If that was the standard, that wouldn't be a problem. And the other thing is that we have many different VCSs. Everybody uses it, so if we had one common one, then everything would be easier. On the other hand, it would be harder to push everybody towards a common one. So I'm not sure it's worth it. But the point is, if we, for example, standardized on one thing, and that was the way for Debian packages, then everybody would just do that. Until everybody needs to install a different version control system to upload to a package and things like that and learn how it works basically and so on. It doesn't make sense. It's too much of a threshold. That's a question over there. Coming back to the actual process of doing one RC back per day and so on, I wonder if you have any suggestions on how to actually find, for me the problem is, I try to look for RC bugs. I find some bugs and then I see, wait, there is a context already to this bug. Somebody maybe has tried to work on it, didn't manage to fix it, so actually finding, identifying good and immune candidates, to me seems non-trivial. Do you have any insight into that? I think Lukas has some spam to add on like this. Yeah, so one thing that, yeah. You don't see the URL? There's no real good page for it currently. But there's a set of CGI scripts using UDD that gives some list of ending RC bugs. But it really requires someone to take the script, improve them and publish them somewhere. They need more love, but just talk to me if you want to work on that. You can, that's. But there is a query online. Yeah, there's one, so. You know what? No. Slash, CGI being slash RC bugs. Slash calls them, RC bugs. Yeah. It's quite easy to write just queries to find specific kind of RC bugs, like RC bug dispatches or. Yeah, it's a bit slow. Yeah, besides that, my source for that is BTS Tomes in the website. It's the BTS Tomes in the .NET page. Do you know that? So, and I started from that and then I've learned to like, having some good eye to spot the good candidates, like you choose the one which are not too young because usually can be, if you have an RC bug against the package maintained by a really active person, usually it will get fixed in a few days and it's really not worth to spend your time on something that will be anyhow by the maintainer. So you usually have to look for the old ones, like more than two weeks or something like that. And then you can fiddle with the releases. And usually what I do is aiming at the one which affect the next release. So, these are my few old of Tomes. Christian? Yeah, I'd like to jump to something else in this area about the NMUs and fixing bugs. I think that all these campaigns are shown that now NMUs are quite well accepted for RC bugs. I can testify that NMUs are well accepted for any kind of bugs actually. We are moving this way in the end. And I would encourage people who would be interested to do that. I do that for localization stuff because this is my pet thing, you know. And if you have your pet thing to fix, a lithium warning you would like to want to disappear, you can go ahead for that. And most maintainers will welcome this. As long as you take care to have a very good communication, as Zach said, this is the best way to start the process and to have a good communication, the very first email is the most important. And I get a few conflicts with maintainers because I didn't take enough to write the first email. And I think we can move this way fast and improve the quality of the overall distribution by doing this. Let's think about it. NMUs are wonderful. I can have a better package without doing any work. So just a comment or perhaps a proposal without even adding a field to a dead control, couldn't we just add, a maintainer is willing to allow low threshold NMUs that could add Debian QA as an uploader field? Yes, the question is, is it really useful? I mean, if with the current throws, you can already go ahead and do NMUs without caring about the low threshold stuff. Is it really useful to add something else? I think, and maybe they're just not vocal today, but there are some developers who don't appreciate having their package in the mute. Maybe they don't come to that point. Well, okay, I can be sure for the next statement, but I mean, there are just a few of them and everyone else want to go a different way. The current throws, which are quite conservative in fact, I think I just find. Agreed. I was the one who pushed for those rules and they were really, really painful to increase. So let's not try to change them again anytime soon. In reply to Christian, I was wondering, so these are the current throws for actually doing NMUs. So if you're uploading a fix for an RC bug, which is older than seven days, you can just add and upload it to delayed too. If you're uploading a fix, which fix is RC or important bugs, then you can go ahead and upload it to delayed five. And for every other NMUs, 10 days. So the last points actually say that you can, NMU, look as correct me if I'm already the author of this. So you can just go ahead and do NMU to fix any kind of bug. Even a wish list bug as long as you give the maintainer at least 10 days. So I think this is actually enough to go ahead with what Christian suggested. I mean, using NMUs to do a regular work in packages. You just start, there is actually a bug. So you're not allowed to NMU a package just because you don't like the way the maintainer does it. That's not acceptable. But you can actually use NMUs to do work on the package of other people. As long as you are polite and you expect all the rules of sending a path that differ, you minimize the changes and end your flow to delay them. Well, those are recommended values. You should not upload, well, you should see make sure. That's the minimum, yes. Usually for, I actually didn't pass NMUs for non RC bugs and I used 14 in there. Because the point is that at least eventually it will happen and they maintain all the needed time to actually react if it doesn't like what you're doing. I just wanted to say that I think that just because people want to have more information available as to what the maintainer's mindset is on his package versus the actual rules as written, they don't need to be like, you don't need to change the rules, right? You need the rules the same and just put in a couple extra fields that are like, this developer hasn't uploaded any fixes to any packages for three years. That maybe should be indicated on the base package website. Or this maintainer loves NMUs, so give them to me. Or a field that says, yeah, make sure you check my Git repository on Aelia. I don't think adding that little bit extra information in somewhere very easy to get to, like the package website would trust anything. And I don't think you need to change the rules to do that. Yes or no? I mean, there is at least the effort of standardizing some field and actually getting it proper. I mean, for the VCS fields, it took like years. So there is anyhow a little bit of effort, but you're completely right. So if the information exists and it's currently on a web page which is completely unparsable and this kind of stuff, it will be way better to actually have a field. But we need someone which actually go ahead, propose it and drive the standardization of this kind of stuff. That's the most straightforward way. It requires no changes whatsoever to like first fields and control. Just to be put a note in Debian and readme.debian is the canonical place to have information on packaging. If you do that, you will have with 10 different ways of writing that note. So you just read it. Tons of different places where you need to look for it. So that's the problem. I mean, the value of standardization that you know where to look for. In readme.debian. What? If you put it in the readme file, which you're supposed to read before you do work on a package, then. You mean readme.source, that kind of stuff. Yeah, we mean that source. We mean that thing, yeah. Yeah, that's it. What else? So just in case anybody doesn't know, I'm one of the primary maintainers of the BTS. And one of the things that has long been a goal of mine to do is to get more people involved in intermuting to make finding things easier, to make identifying RC bugs that haven't been looked at, that need to fix, easier to identify what the current status of a bug is and all the close to things. So there are some features that currently exist in the BTS to make this easier, and there are a lot of other features that are needed. So if there are, it's sort of not totally on topic for this buff, but it's related. So if in between now, and I think Tuesday is when the DebBugs buff is, if you can continue to think about things that would be better, then we can discuss it there. I mean, because I know that finding an RC bug to fix is half the battle of making an immune. Any other comments? So I think the best bottom line is the one that Christian put it as, you all have the feeling that nowadays an immune are welcome. I'm not saying that they're welcome by anyone in Debian, but in general, they are welcome. And that the current rules are both conservative enough and allowed to work on packages of other people. In my own experience, that will let you receive a lot of thank you and really, really few flames. So I think it's totally worth to go ahead and use this kind of way. First of all, to our release to happen, our release is to happen, and actually also improve the work of other in a very, in a quite simple way. So thank you for attending and see you all in depth.