 So I guess we're ready to start then. Are we? Like Locke says so. So we are welcome to the booth about package subringing. And let's start discussing. So I hope you have browsed through the proposal a little bit. But in a nutshell, I prepared two slides to basically show the process, how it would look like. I hope you can read that a bit. It was a five-minute diary, just a second. On top, it says intent to salvage, on the right it says intent to package. Yeah, that's a typo. That's a typo, yeah. The thing of memory was taking control, I guess. But we can fix that right away, more than tech. The idea behind this, when a package looks some kind of un-maintained and feels such criteria, some criterias like it needs some love, there's unpackaged upstream versions, but there's no activity on the package. Then it will be eligible. I think I wrote in the criterias here. You can keep the typos. And if the package is eligible for salvaging, the proposed process would be that one, that the one who is interested in taking over the package wants to file intent to package, against the package, with important sorority, so it kind of sticks out. We talked about that, and we explicitly did not choose to take a serious or release critically one to avoid that that package is falling out of testing, because that would make not so much sense. When this is done, the recorded maintainer or team or uploader can react to that bug and say, no, I do not want you to salvage the bug. This is that object request. Then the process immediately stops. If there's no reaction, or if the maintainer says, oh, yeah, go ahead, take it. In that case, if he says, go ahead and take it, it's easy because then it's just a normal package takeover. Let's say that way. If there's no reaction, the one who wants to take the package will prepare an NMU with his fixes and also the change of the maintenance ship and upload it to delay 7. And this gives also some kind of additional reaction time to the current maintainer. And if it goes through, yeah, yeah, it's his package now, or his package. So that was in a nutshell. And the timings here is like this are the criterias out of the current proposal. So one asset before that the package itself can be considered for salvaging itself, it needs lacking somehow. It needs some work to be done on like bugs. Yeah, no, some upstream release is not packaged, or some, let's say, CWA work on that one. And of course, and additionally, it needs to be only fixable by an upload. So that is a sourceful upload required to fix the issue. And one of the criterias out of the table above needs to fulfill as well. And those criterias are focusing on the activity. So if there is no activity from that maintainer on that package with for six months with the other criterias fulfilled, for example, or there are several NMUs in a row, which were so basically an NMU maintained package. And there will be another NMU coming up soon. And also there if there are NMUs, but no follow up from the maintainer on that one. And if you have a library transition or like which is also kind of painful to have if you have some kind of non-active package but a big library transition, that could be also a good reason to consider that package eligible for salvaging. And the other one is if we have more than one unpackaged upstream version, and it has been noticed already earlier. So for example, if there is version one unpackaged, a package version two unpackaged, and someone filed a bug, please package version two. And then version three comes out. And someone files again a bug, please package version three. So that there's some strong interest in that package getting updated. And that is, and the version two is out for more than one year. And then it's also okay to start salvaging on that one. So that was kind of the process explained in a few words. The mail is or the thread on there is much more verbose on that one. That one, that slide is compacted and might also miss some details on that one. Okay, so then let's switch back to Koby and see if there are already some questions you might have at the moment. But please to make it easier for the ones on the stream and for me later revisiting the video, please use the microphones. I think that if you insist on saying six months or one year, you might miss all the heat of the moment. Probably about after one month of waiting the person who wanted it to get repackaged probably even lost interest. So you really gotta strike when the iron's hot. Yeah, so I can maybe answer that. So I think you're mixing two different things. One is the definition of how do we somehow decide when a package is unmaintained? And the other is once a package is unmaintained how long does it take to adopt it or salvage it? And so the six months or a year is a conservative, I think a way of defining when a package is unmaintained. So typically, I mean, so one thing is we have to keep things in balance. Users sometimes have say optimistic expectations of how fast new upstream versions will appear in Debian. And if package hasn't been updated after one month in Debian, to me that doesn't necessarily indicate lack of maintenance. I mean Debian works on different timescales and roughly speaking, our criteria is stable releases. So I think one month would be too short to a new version appears of some package and I don't upload it in one month. I would find that a bit fast to consider the package unmaintained. So on the other hand, if I haven't done anything for a year, then somebody can take it over in a month. So hopefully that answers your question. Question from IRC then Stuart. Oh, forget it, no, go ahead. No, I mean, can you switch back to this screen? Yeah, there's some wording to do, I guess. I mean, I know this is just like a proposal, but say if there are many cases where you can have a one year period where two people request for one new upstream version, but the maintainer answers to the bug, saying, well, yes, this new upstream version is not ripe enough. So I mean, things like that should be added to the timeline. I think it's already covered by the definition of maintainer activity in here. So in general, to be an inactive maintainer, you have to not respond to bugs. So as it's written, you could respond to bugs saying, hi, thanks for your request. I'm super busy right now, but I'll get to this next month. And that would qualify as activity under these, as I say, conservative guidelines. So by the way, please also make notes in the copy because it will be hard for us to make notes and talk at the same time. So please also enter a remarks into the copy. But I only put my cell phone so I don't think I can use copy. You can also add your thoughts later if you want. I just thought I'd speak up in support of the relatively long durations in the sort of adoption time scale because I think we shouldn't lose sight of the fact that there's a big difference between sort of a particular problem with a particular sense of urgency that might motivate a traditional NMU as being the sort of obvious way to deal with somebody who's short-term unavailable and the notion of salvaging a package implying that we sort of reached a point where the maintainer's involvement with it is unretrievable. It's also really interesting that I had a very different thought about this notion of if a month is too long and you've lost the heat of the moment or the passion or something. If somebody is going to take over a Debian package, I would hope that their enthusiasm is gonna last for a really, really long time. And if a month isn't, is too long to sort of sustain enthusiasm, then years will be a problem. So I'm with you in the corner with us cranky old guys. But I do think we have to think about new contributors to Debian in this context as well. So I don't wanna stretch it out too much longer in the sense that I think a place where I see a need for such a policy is new contributors who want to help and who are blocked by maintainers sitting on packages. Chris. I really like to hear from people who have essentially salvaged packages in the past, like before this proposal, like what problems they've run into and things like that. So yeah. Doko needs a mic or to stand up, one or the other. There's an extra mic. So, well, I did something to a package which sounds like a salvaging that was Lipis CDIO, a package which failed to build in one of the GCC transitions. It was not fixable without updating to a new upstream. No reaction from the maintainer. So what I basically did preparing an NMU and for the second break, I decided, well, okay, I just changed the owner to Debian QA because apparently the package was not maintained and it was blocking a lot of stuff. So can I ask if the new process would have helped you in this proposed process? I assume it would. You wouldn't have had to set to, did you want this package? It would legalize my actions. Okay, but we don't talk about Debian QA here. So, but you could change it to Doko as the maintainer. Right, but usually I don't want to do that. That was my question, yes. Another thing, if, how do we, what are we doing with packages which are team maintained? Say the uploader is going away or the package owner is going away. Uploader is either a team or the package maintainer is a team. There are teams which are working very well in Debian like Pearl and Jarba, but well, the Python applications team, Python modules team is a very loosely coupled team and packages fail down the cracks. So who would be responsible for that? The uploader, the team, what would you do? Toby, did you follow the question precisely? Not one for sure if I got it, but you've thought about team empowerment, right? So one thing is we thought or talked about it, that the team should be have also the same kind of same rights as the maintainer or the other uploader. So if a team, if it's team maintenance should be also go to the team and the team is also okay to object on that one, to object as a region, but on other side that is a really good opportunity for the team to get a new member. So they should, they really should then not say object, they should say, hey, cool. Do you want to join the team? Maybe. I think that wasn't Delco's question. So let me try. I think your question was this is okay, but it doesn't solve a different problem I see, which you see, which is that some packages are formally maintained by teams, but practically unmaintained. Is that correct? So such a package actually would be eligible for salvaging, right? It would meet these criteria, but it would have to presumably someone would be discussing about moving it out of the team and into individual maintenance or joining the team and joining the package as an uploader. Either the ladder doesn't need a new process, right? The ladder is something which is in general possible, right? All teams formally welcome new members. And so I'm not sure I, okay, I think I understood the question, but I'm not sure my answer is very satisfactory. Well, I think it's also, it addresses problems for teams which have a very tight coupling of the members or where the team feels responsible for every package. But I think it doesn't work for teams where you just upload or you join to get upload rights. Right. So I would say that there's nothing that says you can't salvage packages out of a team if the team isn't doing good job maintaining them. There's no special status for teams in that. Right, so I think my suggestion in this case would be that when this reaches the level of a sort of well-documented process or even an element of policy that it just has some explicit wording in there saying, you know, what the alternatives are in the case where there's a team that's involved. Beyond that though, I was gonna comment that I also have been on both sides of the salvaging process. I have found packages that have gone essentially unmaintained and where I had some immediate need for, you know, a newer version or something like that. And you go and you try to poke the maintainer and if they're not responsive, you maybe do an NMU and if, you know, it looks like it's still unmaintained. I've even gone so far in the past, at least on one occasion I can recall of just taking over maintainership of the package and assuming if the other person ever reappeared we could have a gentlemanly conversation about what the right process would be. On the other side though, I find a documented process like this potentially really helpful because there have been at least a half dozen times I can remember in my own history where somebody approached me as the maintainer of some package I wasn't putting much time into and said, hey, what about? And my response was, would you like to be the maintainer of the package? Because I'm clearly, you know, it's not something that's in the center of my universe anymore and you sound like you care about it more than I do. And I've successfully handed over at least six packages that way that I can remember. So if this encouraged more people to think that it was okay to go poke even a well-known maintainer who wasn't doing the right thing for package and take some action, that would be great. Tico then, then too. Oh, so I was thinking that as you know, world birth rates are dropping. So Debian will be affected too. So you have better start expecting less maintainers coming in than dropping off. Yeah, I think we won't solve that issue if it is indeed an issue today. I think the mic's muted, Poyo. It's on my side, okay. If I understand well, your proposal is to add an ATS type of bugs to the BTS, right? But like, we already have the possibility to open a package and then adopt it. I don't see what this procedure with a new bug type is adding compared to the old process. If we could decide that it'd be okay to open packages quicker in the same amount of time, like six months. So there's no process for me to orphan your packages, right? Correct. So the difference here is about who's filing bugs. If you're an inactive maintainer, that if you're orfaning your packages, that's activity, right, that's contributing to Debian and you're actually, that's a maintenance step for the package, right? Currently, I can ask the MIA team to do that for me, right? No, because Toby can answer this better than I can. The MIA team can do orphaning. We have some scripts for that one, but that's not the normal way. Usually it's that the maintainer should do that themself. We do that if the maintainer doesn't do it, if he does not react and it's a... But that's the case we are trying to address within six months of no response, right? But it's actually all or nothing. MIA is all or nothing. So if I'm not maintaining one, okay, let me be honest and say, there's at least one of my packages that should be salvaged. I'm not proud of that, but let's be realistic. So what Toby can do, if I don't get around to doing something about that, which is part of the problem, right? Me not doing something, then Toby can orphan all of my packages and declare me MIA, but that's a bit extreme because some of my packages I just uploaded yesterday, right? So I'm clearly not falling into the MIA process and the MIA process won't get anywhere with me. It would be actually that way. If someone tells me, hey, David is no longer, it seems to be MIA because package XYZ has not seen an upload since two years or something like that, I would check and would say, oh, he just uploaded the packages, some packages yesterday and would respond, sorry, he's clearly not MIA. I cannot help you. Okay, so then we have two cases here. One is where somebody's not responding, right? After six months, it's okay. We can take over the package who could ask the MIA team to orphan it or you could decide to orphan it yourself because you recognize it and then somebody could ask you to orphan or fund the package. Sure, but I won't answer because I'm doing a bad job of this package, right? I mean, if I would deal with those responses, then we don't, if I would answer your email like a nice person about this package, then we wouldn't need this process. But then you're in fact asking for a third party to orphan the package for you and you call that ITS. No, no, you file the ITS bug because you want to take over my package, which is... And then if you don't want to, you reply to the ITS package and close the bug? Yes, but presumably, that is no more effort or that's about the same effort as orphaning the package, right? So if I'm willing to put that much effort into the package, then okay, I'm still... I agree, okay, look, there are many ways we can game the system in Debian, right? There's some fascinating Lintian bugs. But we can't build the system on the basis of developers are hostile to Debian, right? So this process actually assumes that I'm well-intentioned, I just have spaced out this one package, right? So I'm not going to... It assumes that I'm going to mostly be honest or no more deluded than we all are from time to time, right? And so when I see this bug, I'm gonna say, oh yeah, that's true, I should have done something about that and I'll either say great, do you go take it or I'll say, oh my God, I can't deal with this right now and you'll fall through and take over the package. And Rico, there's a standing mic too, or we could pass, would people rather pass the mic around? That would be great. The cameraman would probably rather we use the standing mic. Yeah, okay. Just wanted to say that for maintainers that are actually hostile to Debian, we have other kinds of processes. All right, right, more questions? And Rico, please come back. We've been discussing this since Portland, more or less, which is one, three, four, five years, something like that. And there's every time a pretty good consensus, but it hasn't gone into implementation yet. I wonder, so I was wondering about this this morning, is it because there's not many packages to be salvaged, is it because there's not many people that are looking forward to maintaining more packages? Is it because of being afraid of some social reactions, like there's a taboo in taking over packages that we haven't gotten over? Is there a list of salvageable packages that one can look and say, let's stir the waters and give it a try? I wonder if there's blockers that I'm not seeing. To adoption of this. So let me refer back to a previous comment about BDALES, about when this hypothetically ends up in policy. This, I think, won't ever be in policy, because policy is about the contents of packages. I mean, okay, that's a debate, but it feels like it's not a good fit for policy. That's a debate we could have separately. The maintenance guy, whatever. Yeah, so some people think that's an important distinction. So I think it's a politically difficult thing because we have a good process for fine-tuning the contents of packages, but we don't have well-defined process, well, other than going to the TC for changing package maintainership. So that's why I think it has been slow, and I think the proposal is to put it in devref. I'm interested when people think about that, if that's where the NMU guidelines are. And to me, this feels like something a bit related to the NMU guidelines. It's also maybe not a perfect solution, but it's better than the other ones that I can see. I know Sean will knack its inclusion in policy. Okay. I really don't think of those two as being hugely different, even though the scope and the bounding and sort of the degree to which we're expected to adhere to them is clearly different. But in my mind, they're both sort of, how things get done in devian documents. So apologies for generating the confusion. Okay. Thank you for creating that confusion because it gave me an opening to say the thing I wanted to say. Enrico said about the social impact of that. So from the MIA team experience, we have cases where people send us some ping and say, hey, look at that package. I would like to have it. And the maintainer seems to be away. And well, usually if there is not already a process ongoing, we have to tell him, okay, yeah, there's a point that data looks like the person is actually MIA, but come back in half a year because then we can give you the package. And this has a huge social effect, I guess, because in half a year, he lost interest, probably, likely. Or maybe he thinks, yeah, okay, if devian does not want me to help devian. Screw them. And they, yeah, on the other side, I think we always saw that flame war about that unfortunate high check. Okay, that was, that check was not in order, but I think that is also, but if you think further, this is why I think we need to have some rules here, something to rely on, something to back up, some servicing to avoid that you contributors get, yeah, shout at because they wanted to help again and did some work on a package and then got shouted at. That is really demotivating and you're really likely to lose that contributor forever. So could you clarify what, what side which you're referring to? I'm actually, I'm not familiar with it, sorry. Say again. Can you clarify, look, sorry. Can you clarify what specific incident you're referring to? Because I have no idea what you're talking about. I missed it. Oh, the hijack. Okay, sorry. So going back to Enrico's question about how many salvageable packages there are, whether there is a need for this, it's kind of anecdotal but I think people who hang out in the user support IRC channels and it's probably the same on some of the mailing lists, it's a relative, it's a frequent enough occurrence that it's sort of, oh, one of these is someone comes and their motivation is I would like a newer version of this package, right? And you tell them, well, you can file a wishlist bug and they say, oh, well, I did that or whatever, they're blocked and in some fraction of those cases, the person says, okay, what would I have to do to update this package? How can I fix this problem? Those are the people we want, right? How can I fix this problem? So even if it's 10 people a year that we could bring one step into Debian, I think that would be a huge win. And those could get motivated to do more work in Debian as well. Right, I think we can trick them into joining the MII team. More questions? Next steps, I think we should, everybody in the universe watching this stream across, you know, for thousands of years as it radio waves spread out, should send in their comments. So far, the develop thread seems to be a useful discussion. So that's a reasonable place to carry on discussing it or just add it to Gaby here. I would say we make another draft and then we propose a patch to Debra. Yeah, I think Debra would be the best thing to have it in Debra. And yeah, so no one objecting to that. This must happen before next DevCon, which means Toby has to do it. Yeah, I know Universal turns out to be kind of an overstatement. Galactic operating system, I think is a good start. Hi, can I expand my question earlier? So I previously asked who has salvaged packages before. So I'm wondering if anyone's had their packages salvaged beyond Beedale and how it felt, what they felt the process was, what they liked about that, what they didn't like about it and things like that. Because I think getting, because this is obviously a new definition of how to salvage a package, but we've sort of been doing this sort of thing for a few years just informally and in lots of different ways. So I feel like there's a lot of prior art lying around. Like, oh yeah, this guy took my package and it was fine. Or I remember this time someone took my package and it was suboptimal because of XYZ. And hey, why don't we try and address XYZ in advance? So. Do you really expect these people seeing here in this session? Well, there was one sitting here. I'm not sure the package involved. So I've become co-maintainer of packages that annoyed me. And then felt an irrational annoyance at the inactive maintainer, which I recognized as irrational and eventually got over. And then after seven or eight years, dropped the inactive maintainer from the field and said, hey, if you wanna be put back in, answer this email. And no answer. So I think that maintainer's now MIA and I mean, it's not a very dramatic story, but that was my experience. But you haven't had any of your, hello? You haven't had any of your packages? Salvage, no, I've ITA'd them and I've given away packages or attempted to. And actually I have failed to give away packages because I wasn't willing or able to put in enough effort to do the transfer of maintainership. So I was like, great, take over the package and the new contributor was like, yeah, what is this get thing? I, you know, help. And so that failed. I failed. And would this process have helped? Would this pretend reproposal help in that respect? No, it would not have helped that specific situation. Can't help everything, but if you try and plug all the gaps as much as possible. Yeah, that would be sort of making me a better helper of other people. I think that would be the gap that would need to be filled there. Not that to policy. Yeah, by name. Bremner must be more helpful. I can see Sean typing curiously. Will you envision any, will this work for the M2 like straight away or any clarification will be needed or something like that? Well, I think we could give it a test run already so to see how it works out. But at the moment I think as it's not kind of formalized or established that could be some backlash. Can you hit the question? I didn't hit the question. Sorry. This process like looks fine if you have access to the archive, if you are DD. What will happen for people that doesn't have access to the archive that is only DMs or need a sponsor? I mean, I, this person will fill the ITS bag and then it will have to find a sponsor. Right, I think it should. But I think sponsors will. Sounds fine, but I mean, I think it should be clarified like, so people is not afraid of like sponsor that upload after. This process should be not affected by any way how to upload things. So it should be a normal uploading process that then getting a sponsor and getting sponsored. And I think that proposal would also help on that one. That you find sponsors willing to do the upload. Yeah. Because sometimes I quite a little bit of reluctant to do that. Yeah, I agree. But it's a lot harder to do an M-M-U when you are DM than when you are DD. I mean, when you are DD, just go and do it. I think it should be like. There's an extra step, but it could be that you write in the title that you intend to salvage the package, for example. And that would help because, for example, out of my QA work in the MIA team when I browse mentors and have a few hours to kill to sponsoring, I actually prefer those bugs who want to adopt packages. Yeah, I mean, so it's true that getting M-M-U's uploaded is hard for non-uploading, for non-uploading DDs. But our C-bugs are actually not bad, right? I think my subjective impression is that people can, by marking bugs as RC, and there really being RC, get M-M-U's uploaded reasonably easily or reasonably painlessly. And so I would second Toby's idea that marking things as ITS, I mean, it will hopefully become a comfortable process. People will say, okay, yep, this is following something we have consensus on. It's not a crazy thing. I'm not going to have a flame war about this upload. And I think that will help just to sort of repeat, I guess. Do you expect this process that people could do QA work, just identifying packages that would be good for salvage or not only if you really want to salvage the package yourself, you should. I think you shouldn't file an intent to salvage bug unless, but this could be an add-on proposal, I guess, to mark packages as need salvaging or something. Yeah, I was just thinking of, for instance, the triaging bugs work, the salvage is doing, well, some of the people are doing too, but that helps triaging bugs to clean bugs from packages, then it would be something that, when people are triaging bugs, they could recognize all these packages poorly maintained and maybe just to flag the maintainer that your package needs some love and if you don't care for it, then. Right, I like that idea because, yeah, often in box version, you come across such packages which you say, yeah, I do not have the time for that or the energy or it's not my, I do not use that package too often, but still it could use, we have that newcomer tag, maybe they can reuse that for that one to also to have some attraction for people who want to help, maybe like. I like the idea, but I'd like to make it a second step because I worry that the political challenge of getting Debian to do anything is sufficiently high that I don't want to block. But let's reserve that idea for next year's DevCon because then the salvaging process is hopefully active and then we need new topics to cover, but actually a good idea. I mean it could sort of distribute the work of the MIA team too, I mean in the sense that you notice that all of somebody's packages are marked as needing salvaging, you say, this is an indication that further. Yeah, maybe we want even to have our own tag for that. I really think that it might help also maintainers to, like just being poked about their package that are not well maintained and they might just come back to life. Because most of this criteria involves bugs already being filed on the package and the maintainer not responding to them, so maybe they'll respond to this ITS because they're motivated by some irrational ownership of the package and say, oh my goodness, I'm going to lose this package, I should finally step up. Maybe it will be a bit of a stick in that sense. We'll have to see, I guess. So we got one minute left. We give Enrico last question. In any case, that conference is still a few more days so we can also discuss here. Since you mentioned Debbie and the bell, there was a thread I went to see. Gregor Ehrman has a much more simplified proposal for the salvaging policy bid. It's unfortunately not a one minute thing but if we have consensus, I mean, I see no problem with that and, oh, yeah, that one. Would we have a consensus also on something like that? That the proposal came quite, I saw it just half an hour before the talk here so I could not really digest it already so but I think that is also something we can discuss. Of course, this will be more than one minute so let's defer that to the mailing list or to in-person discussions here. I would prefer to have some written communication to avoid that information is lost but we can, of course, we can also have a talk. Both, right, maybe it's useful to talk things over in person and then send a mail to the list to include everyone. That is quite productive and much of the proposal has been done that way. Okay, time to let the video team go. Good, thank you very much. And let's go forward with that.