 OK, cool. Right. Hi, folks. Hi, Jacking. This is very much a boff. I'll reiterate what I've said in other sessions. This is not something where I'm gonna tell everybody what I think should happen. This is a session I think we should be having for the sake of having a discussion. So, please, speak up. Arall yw ydych chi'n gaeth eu cyfnod o'r cyffredin llwyddoedd ar ôl y cyfnod, a'r cyffredin llwyddoedd yn fawr i'r cyffredin llwyddoedd. Dysgu chi'n gweithio'r cyffredin llwyddoedd. Ac mae'n ddweud o'n cael ei bod yn cyffredin llwyddoedd. Mae'n gweithio'r cyffredin llwyddoedd. Mae'n gweithio'n cael ei wneud i'r digwydd ac yn ymddangos rhai yn maen, ac mae'n fawr i'r llwyddoedd. So, As I'm guessing a number of people have noticed we've had several heated discussions on Debbie and Devel and elsewhere in the last few months about the topic of hijacking. Wether you describe it as hijacking or aggressive enemy-ing or offening and taking over packages, there's a whole continuum of describing basically taking over maintenance of a package from an existing maintainer. Is that ever right? Is it ever something we should do? I've seen some people suggest not at all ever, no way 100%. I've seen other people saying, yeah fine, go for it. So what do we mean by hijacking? Is it acceptable to take a package if a maintainer is basically missing in action if they haven't been around for five years and may also never get responses? Is it okay if you think that a package is unmaintained? Has it not been uploaded for three years or so? Is it okay if a package is badly maintained and it's arcy buggy as hell and the maintainer isn't doing anything? Is it okay to take over a package if the maintainer isn't doing something that matches what you want? Is it okay if the technical committee say it's okay? What do we think? Anyone? Ian? I think sometimes we will use the word hijack to include situations where the maintainer seems to be absent or anyway isn't resisting. I'm not sure that that's quite the best way to define the problem. The problem comes surely when the existing maintainer or maintainers are clearly unwilling rather than just not cooperating or failing to exist entirely. Exactly what to do about that situation is something that we have struggled with for a long time. I don't have any good answers. Salvage, he's suggesting for a situation where the maintainer is just not apparently there. There are some situations in which the maintainer himself is not necessarily MIA but is effectively MIA for some packages. I personally think that waiting for a maintainer to be fully MIA on 100% of his packages might be too late when some packages need help before that. It's perfectly reasonable for one to have lost interest in parts of the archive or his packages somewhere and we currently lack a clear way to just take away packages from a maintainer. I don't think we entirely lack a clear way to take away maintainers from a package. There is the QA offening process which I have done to a few packages where you file a bug saying this package appears not to be maintained. I propose offening it and it's three months later offened it. That's a really long wait. If no one replies to the bug I don't see what possible harm it could have. That's almost what I was getting on with if the maintainer is absent. In that sense it's certainly not controversial and you can see that it's not controversial because by definition there's nobody who's opposing it. The question is under what circumstances should we grasp the package and force it out of the existing maintainer's death grip? Historically Debian has had a very strong maintainer culture but we seem to be moving away from that. There's also the difficulty that our nominal system for taking packages away from maintainers is the technical committee who have never done that. Frankly I don't think they are very likely to in the future. It can't possibly be right that no package in Debian has ever been wrestled away from an unwilling maintainer. There must have been cases where that was the right thing to do. We obviously lack a way to do it and an idea of when that should happen and who should decide. It's clearly an emototopic. One of the strengths of Debian is that we allow maintainers control over their packages. It's one of the ways that Debian scales well that we don't have to have group discussions over everything that we do. But it's also one of our weaknesses that there are a number of maintainers that I've seen who are very territorial about their packages and don't want to accept help. There are people out there who will respond very aggressively if you ever deign to NMU their package for Nazi bug for example, which is unfortunate. We're trying to work together as a team to produce the best operating system we can. I pointed out that the technical committee have never handed over maintenance of a package. Do we think that's correct? Should we explicitly ask the tech committee to step in in these situations? Should we have another mechanism? When I said we don't have a proper procedure, I think it's right that we have some guidelines or it's somehow widely known that we should go to Debian Devil with some delay, something like that. Maybe having multiple steps written down in developers reference saying if you think a package is outdated too much or that it should change maintainer, this is the procedure you should follow. Step one, send that type of mail, wait that amount of days and step two, go to Debian Devil with that type of mail, wait that amount of days etc. Then everybody is aware of what the procedure is, in which step we are for which package and then it's also more clear. I don't know, just throwing out the idea. What people have said so far about going through the QA process and checking on things and offening a package if the maintainer doesn't seem to be around, the weird thing about that is it's not like there is a defined QA team, every developer is a member of QA when they feel like. If we go for that way as a method then you could just say as a member of QA I'm saying this package is orphaned and then potentially 10 minutes later say I'm going to take this package which clearly is not within the spirit but technically is correct from what some people have suggested. I think that document the process, if you are willing to hijack the package or if you are noticing something you can go directly to the missing in action database and document the process by yourself. I mean it's public and you just need to read it and put a tag for it and that way the maintainer will be also keep on the missing in action team rather. So we seem to have focused on packages that are effectively orphaned. I think Steve you were also talking about packages that are maintained but maintained possibly in a bad way. Yes. Well I'm looking to stimulate discussion about all of these places. I mean there was a particular example that we've had recently and I don't wish to pick on individual people but I'm going to pick an example of the wine packages where we've had a maintainer who doesn't have the time to do the maintenance yet still wants the maintenance to happen in the way that they want. While I understand obviously, let's be honest, Debian is full of people with strong technical opinions who are always going to want things their own way. Also in my opinion there should always be a time when if you're not doing the work you don't get to dictate how it's done. Again it works that way of course that when you are doing the work you get to dictate it. At what point do we say, actually no, here's a cut off you've gone too far. So I'd like to agree with what you just said there and suggest to Steve that we should try to narrow the scope of this both to situations where there is an existing maintainer and they are actively resisting the package to transfer to a new user. Even if that only means that they are answering emails saying no. In the other situation it's not controversial, we already have processes that deal with that, they may or may not be too fast or too slow but that's not the really difficult question. I think the bad problem we have is that we don't have a good answer, the difficult question of when is somebody not being a good enough maintainer. Does anybody have any ideas about firstly how badly maintained a package has to be before you want to depose an unwilling maintainer and secondly who should be making that decision. Leo. It has to have some kind of context of the package itself and its role within Debian. If you're talking about a leaf package that only a small number of people use then so if you're talking about changing the maintainer of one of the base packages or something involved in the tool chain you've got to have a much wider approval for that. How do we bring the type of package into the equation as well. It's not just about how actively the existing maintainer fights, it's also about how important is that package and proper maintenance of that package to a wide project. Can we come up with a reasonable set of guidelines to give us help, to give us a process. Should we have to wait for five other Debian developers to complain that this package is clearly not being maintained well enough? Should it be ten? Is that a valid thing to count? Should we say that this package is ex-releases behind upstream as well? Should we say does it have this many RC bugs? In some cases there may not be RC bugs but a package is clearly not being maintained adequately. It's a difficult one to call. What do we think? I'm seeing half of the room not saying anything at all. Is email important? Neil, to the Neil. One of the things that we've been considering for a number of releases is essentially blocking and removing from testing at freeze time any orphaned packages. Because if there isn't a maintainer then that's just going to create a problem. Sure, I've seen that, essentially being orphaned as an RC bug. It would be interesting to get a view on if people would like the release team to take other factors into account on what we should do around releases, including maintainership. I'm quite keen not to have the release team essentially deciding who should be maintainers of packages or directing maintainers to do stuff in that way. You don't have enough people hating you already. But it would be useful to get some feedback if there's something they want to say the release team to do specifically for release time. That doesn't help unstable, which we try not to touch as much as possible, but that might be another thing which we might be able to look at as well. The thing that Neil just said there about the release team not wanting to decide who's the maintainer of a package. I think that's sort of hitting the nail on the head there really because nobody wants to be making these decisions apart from the person who wants to take over the package. Everybody else is just going, oh my God, please no! The effect of that is that really very bad situations of the maintainership of a package can go on for a very long time and everybody gets really embittered and nobody is willing to make a decision. The result is eventually maybe somebody gets beaten down and walks away from the package or maybe they don't. That's kind of war by attrition and not the best way to do things. Or maybe they bounce it to the tech committee who then only get it once it's already a flame war. If it gets to that point then generally the maintainer who loses out will often resign from debbing entirely. If it gets to that level of animosity. As I said earlier it's an emotive decision people really do feel strongly about this. I mean actually we have the low threshold NMU page already to show for those people who are happy to accept help on their packages. How many people here maintain Debian packages? Right, leave your hands up if you're not in the low threshold NMU page. Next question is obvious, why not? Adam just said he's not there because he's never been bothered to go and do it yet. Ian. I prefer, there are certain mistakes that people can make with my packages and I would prefer them to ask me in advance. Every time anybody has emailed me saying I propose to this NMU I have replied very promptly in general yes sometimes yes but watch out. Okay cool, Neil. Hang on a second, just a quick point perhaps we should give people one hijack that they're allowed to do. At the moment everybody's allowed to hijack as much as everybody else. So you get to do one hijack if you're really under all the same circumstances but you're only allowed to do it once. And then whether it was a success gets reviewed at some point and you're never allowed to do it again. If you did it wrong. So people have this sort of token that they value and they're not going to waste it on just mucking about. They take even more responsibility about and then it gets reviewed and afterwards yeah fair enough you can have your token back. Okay, cute idea who reviews it. I think the court of public opinion will have decided at some point later whether it was a good idea or not. Phil also what happens with that if you've actually got a hijack that involves a chain of packages you've got to take over two or three. It becomes a number of packages that will form one hijack then or sometimes you actually need to take over friends. Oh it's clearly doomed to failure then. Well that wouldn't mean an instant team packaging thing which would probably be better than the previous situation. That's one of the reasons why I'm not on the low threshold enemy. It's actually I've got the vast majority of the packages are already team maintained. And if one of the team doesn't get back to them then that's a problem with the team and we need to sort that out. I'm on the low threshold enemy page but also with comments I mean that if its team maintained go there first and I mean it's also protected by the fact that normally enemies mean that you fix a bug and this bug has not been answered. So I mean it's mostly for the case where I'm away for some reason or just out of internet for some time and that it's better to have maintained packages than just me maintaining my packages but I mean that's personal. I agree it's related it's not key to the problem that we're trying to solve here. And I see yes we're talking about Aussie buggy packages where a bug is closed without comment on the bug for example. I'm not going to go looking at the bug number. I mean let's not I've already done it myself let's not pick on particular maintainers particular packages here. You know there are lots of examples out there I'm sure we're all aware of that. Quick show of hands is a metric should it just be done with the least critical bugs. Yes no hands up for yes. Okay should we just describe that say that a package should be hijacked solely if it has released critical bugs that are not fixed. I see two hands out of a room of 20 odd. Should it depend on yes sorry that package question was really ambiguous. Yes thank you Phil should should we define whether or not a package should is available for hijacking. Depending on whether or not you know it's it's behind upstream releases. No should you know. Yeah and we're not frozen yes. Right Vince. Currently if you're behind upstream you just get a wishless bug yes. Do we want to look at perhaps say using a metric to go. If you are 20 releases behind or pick a number of releases behind. Mainline then that bug becomes RC and therefore you can just do any music. Yeah maybe or rather than say 20 releases say is it a year behind or or that kind of thing. Yeah it might be reminded that enemies can be done for wish list wish list bugs. I mean the developer reference explicitly doesn't does not say that you cannot do it. So you can do it given reasonable explanation and time. Of course who defines what's reasonable Neil. So a quick comment about the RC nurse of new upstream version bugs. If there's something that's efficiently behind then that it's like really really out of date. Then just talk to the release team and if I think it's reasonable I'll just make it RC. That's probably the easiest way of doing that. In general I think each one of these are our indications of a package being un-maintained rather than a stock entry of things we should do for each of them. So certainly a combination again it's a fuzzy logic human potentially thing that has to be done. You can write things that might find candidates for this. But in the end I think it's something that the project of people as a whole have to say that one there in my judgment is un-maintained that one isn't. And trying to get some criteria for that fuzziness is NP hard. Well quite I know someone in this room came up with not that long ago his own equation for describing how badly maintained a package is. Didn't you Neil? Would it be helpful to actually have an even semi-official check on every package? So the QA team I think Luke has implemented this. There's a package called bypass not a package a page called bypass and it's basically about packages that are poorly maintained using various metrics. It's very tempting isn't it to think we can only come up with some kind of formula, some kind of objective criterion then none of us would have to make these difficult decisions. Yeah absolutely. That's really what's going on here. But it's a difficult decision and if we have these kind of criteria you can guarantee that people will game them. And there will be arguments over whether something is really critical, the things that we put on the list for you might be hijacked, if you don't do them we'll get it done and everything else will be left alone. All of these things will go wrong. We will end up with rules lawyming. What we need is a way to use the existing social mechanisms that we have and somehow get enough weight of opinion behind a decision without getting the whole thing into a nightmarish flame wall on the way there. And how do we do that? Well it's almost like we need a low hijack page where you say that I'm okay to be hijacked? And it almost feels like I want to file an email to whatever PTS such that on my package page it gets that little nice box saying low NMU if you want to just do one thing or low hijack if you want to continue maintaining it. Sure. Good luck. The RFA tag is already some part of the way though isn't it? No, I don't want to orphan it or request for adoption because I'm still maintaining it but if I fall out of the earth go ahead and hijack it. Yeah, that's fair. If you have better agenda or whatever. I suppose of course the only people who are ever going to sign up for that are the well-behaved maintainers. Well for me if I put that up I wonder if anyone will ever hijack my package because I don't think so because I'm like leaf and unimportant. Sure. I think that the idea of having this kind of formula is quite interesting. Maybe adding some kind of more subjective data and not making it authoritative but maybe an indication would be useful because maybe you don't know that your package is so bad but all the people think so and maybe as a repository for packages that need help and maybe something less drastic than just saying hijack but maybe offer help or whatever it could be a nice way to help to get the social fix done. I mean a technical aid for a social problem. Yeah. Passapata Hector. A lot of questions. Who maintains a package. I think teams should take preference over individuals. I like the idea of teams maintaining packages. Of course the teams have to organize themselves on who leads that team and who has to make the important decisions. That was one thing. I have hijacked a few packages and I have filed wishlist bugs to update the packages to newer releases, upstream releases. The maintainer haven't replied. I've been working with upstream trying to fix bugs in these packages and after a year waiting for a reply from the maintainer I just changed the maintainer upload and there was no complaint at all. I mean those guys were lost. Sure. So you've hijacked and you've got away with it. Is how I describe it. The existing maintainer hasn't complained. Salvaged. I mean it's in the bug report and I really explicit that I was intent to hijack the package. I mean I give it like a year at a time. I mean again but you talk about teams too. Teams are typically better but not always. I've seen some packages maintained. The maintenance has been twitched to a team and the team has been essentially one person. Or even worse you end up with a team maintaining a package and actually if you look at the team there's only one person really active. Or the other problem there's three people potentially active but when they get a really hard bug they all sit back and hope that somebody else is going to deal with it. We've all been there surely. Maybe you could put some light or so. I have also been hijacking or salvaging packages and the way I did it is I sent a mail to Depp in Devils saying and explicitly CCing the maintainer saying I intend to hijack this package and I intend to do this in one month's time. Please anyone including the existing maintainer rise ahead and I got zero answer. So I just went away. If we codify something like that in some sort of procedure to hijack I mean that's quite sane because we rise the red flag publicly before doing it with a reasonable time frame. I mean one month is reasonable for almost anyone and then it's also on a public place where anyone can comment and if no one comments then we just go ahead. Sure that sounds very reasonable. I mean so intent to hijack a month. Salvage definitely. At what point does it switch over from a former hijack to a salvage? This is a very important. I think we need to concentrate on this distinction between salvaging and hijacking. Salvaging occurs when the original maintainer is not resisting. Hijacking occurs when the original maintainer is resisting even if that resistance consists only of sending e-mail saying no. And this is a perfectly clear distinction and this means that you can basically always get away with salvaging because nobody is going to object. And that's the basic way this has been going on and I don't think that's even... The idea of doing that as a rule isn't controversial either. A difficult question is hijacking. I think that's a good point Ian but doesn't policy currently forbid hijacking? Some people seem to think so. I've been told that repeatedly. Perhaps it would be an action from this meeting to actually put in the premise of salvage into policy as an actual actionable thing. So it's clear in the policy document. So when this kind of thing comes along... Well volunteered. I didn't just volunteer. You just did yes. Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Ha! Right. So maybe we can just do a difference between salvaging and hijacking with salvaging being like between common sense humans and with no resistance and then if there's resistance refer that to whatever probably technical committee because there's a disagreement on some technical question I was very interested in Steve had this crazy suggestion of the sort of magic hijack token. I thought that was really interesting. Something like that might actually work on the grounds that it doesn't depend so much on having to persuade some other bunch of people who haven't been involved in the previous history of the package that there's a problem and making a huge public flame war over it. Another possibility is that the technical committee might be somehow encouraged to take a more active role in this. Now at the moment the technical committee is, that would be, Phil suggests yes maybe the technical committee should give out the tokens, that would be a possibility or it could decide to restore the tokens afterwards. Interesting idea. Now all of these things are possibilities. Now interestingly the technical committee is currently in the process of, we're going to start a number of GRs, mostly kind of constitutional bug fixes, but one of them is a thing that I invented which is a piece of advice from the developers to the TC saying, we would like you to be more or less aggressive and that kind of thing will be very influential with the technical committee and if I would encourage everybody to participate in that discussion and if you think the technical committee should be more willing to hand over packages away from existing maintainers then that's something that we need to know about. Do we have any questions from IRC at all? Is anyone following? No, okay. No actually going through with that it sounds like a reasonable place, maybe the technical committee would be the right body to give people back their tokens after they've been used. That sounds like a good way to go. The only comment from IRC is that people think that WNPP is easy to miss. So it's listed on the PTS, it's listed in various other places, you've got to remind emails now. So it's interesting to see why people think that and maybe we need to publish that more again and say when we're going through this. Of course, the downside of the WNPP of course is that the bugs don't actually appear on the packages own bug listing page that I'm aware of and it would be much much nicer if they did maybe, I guess. We have a solution for that Steve, we have the effects control message that you can use to make that happen. Sure, I mean would it be useful actually just to add an extra extra piece of code on it, you know, the BTS is clearly easy to hack on, you know, to add specifically any RFAs, orphans, whatever request for helps into the bug listing for the package itself and not just in the WNPP bug listing. Maybe, just a thought. So we have what sounds like a reasonable solution for salvaging. How long should we leave a package before we consider it that it's in need of salvage? So Steve, I wanted to say something about the WNPP bugs. Maybe it's a good idea to start moving all the requests for help, requests for adoption, whatever bugs into the package itself instead of WNPP and use user tags to find them and stuff like that instead of collecting everything in WNPP. Okay, maybe. Please, I hope people are taking notes on all this. So salvaging, how long should we leave something? Just a question about salvaging, if a package is removed from testing or a package is removed from SID and you've introduced that salvaging and you fix all the bugs and make it transition and that's fine. Without any wait periods before we start discussing wait periods? Again, it's really quite easy to get something removed. Believe me, I've done it a lot. If you then immediately upload, there's nothing stopping you basically hijacking any package that way. And again, that isn't salvaging. Should we wait for the bit to be a nasty bug out for a month? Should we wait for it clearly to be not maintained? But how do we sell it clearly not maintained? What I would put in an eventual reference would be whatever discussed us with people and if you or anyone else think it's reasonable to salvage this package, then just go ahead with the rest of the procedures that might be one month's delay announced on WNPP. And I mean not codify what leads to this situation might be just insane enough if we have the rest of the procedure reasonably written down, I think. Sure. Right, absolutely. And it's important that if we don't have to say why somebody wants to salvage the package, all we have to say is the existing maintainer is not resisting. And that will avoid us getting to the situation where people claim to be salvaging something, but actually they want to hijack it. Correct. So, okay, we have a salvaging process. When the maintainer does argue, because of some who will always, and then it becomes a hijack, what do we do then? Do we let an existing maintainer essentially poison the well and make sure that the package is never going to be effectively maintained? Or at what point do we overrule them? Do we just at that point bounce it straight to the tech committee before we have the flame war? I have been trying to persuade my colleagues on the technical committee that this is something that we should be doing. They're, I think, not all entirely convinced that they, A, want to do it, or B, could do it. One of the GRs that we are proposing is to make it clearer that the technical committee should be allowed to have private conversations with people who are raising an issue. And that will make it hopefully a lot easier. You will be able to go to the tech committee and say, well, I sent a salvage request to this package, but the maintainer objected. And actually, look, it's not really maintained at all. You know, what do you advise? Can you help? And then the technical committee might look at the bugs and might email the maintainer and have a conversation with the maintainer. And hopefully either the problem will be sorted out or the technical committee will become convinced that the hijack was actually necessary in some kind of marvellous ideal world. Okay, cool. I think we have answers. Do we have any more opinions? Any more questions? I'll see. I guess not. I would like to say thank you, Ian, for coming up with salvaging, which is something I have not. So it was you. Phil, we're very, very sorry. We've stolen all your ideas. We need to file your name off. Apologies. Yes. Ian corrected me unless you knew what it was his. Phil. So, yes. Thank you to Phil for coming up with salvaging. It's a very descriptive, useful term. And so, yes, I think we have reasonable guidelines. If you think something needs salvaging, say so. And describe it as salvaging in your mail to Debbie and Devel and CCing. Ideally, the team maintainers, the maintainers individually, any uploaders and let them respond. If there is a real argument and people really don't want to either fix the bugs that they've been neglecting or that you take it over, that's the point to take it straight to the tech committee and we'll keep them busy. Now that they're having monthly IOC meetings, hopefully a lot of this should happen more rapidly because, again, a month is a reasonable time period, I think. Okay, thank you everybody for coming.