Gobby for the Bof "Let's starting salvaging packages' ===================================================== * gobby infinote://gobby.debian.org/debconf18/bof/lets-start-salvaging-packages * Video: https://ftp.acc.umu.se/pub/debian-meetings/2018/DebConf18/2018-08-02/let-s-start-salvaging-packages.webm Questions/Ideas =============== (if you put them here in advance, please also try to make it to the BoF to explain it to us; of course only if you are at the venue) - it would be nice, besides having an ITS (intent to salvage) bug opened on a package, to make such bugs visible to bug triagers, so they can see that a package is poorly maintained. → that would be a good addon but as a second step - see also proposal by Gregor Herrmann: https://lists.debian.org/debian-devel/2018/08/msg00008.html assuming a list of packages in need of salvage can be compiled automatically (because the metrics are tight/clear enough), would it make sense to have some visibility for it (similar than we have with the autorm notifications shown in pts/bts etc)? that way, we could imho better encourage people/new blood to engange in joining teams/helping out because the need is transparent (and making maintainers more aware of it, resulting in them letting in new people easier/earlier as they would otherwise). Notes ===== - eg. replying to bugs is considered activity, - "formerly team maintained packages" → would be also fall under this; teams should be encouraged to ask the salvager beome team member - team maintained packages that are actually maintained don't need this process -- use usual process for joining the team Q: what if a package is team maintained, but effectively unmaintained? A: it would be as eligible for salvaging as a non-team-maintained package. Alternatively, the person with interest can be invited to join the team Q: what is the difference between salvaging or orphaning? A: there is no process here for orphaning a package. If you're orphaning your packages, that's maintenance activity. The MIA team can do orphaning, but they do that to all the packages of a maintainer if the maintainer does not react to pings and goes effectively Missing In Action. This does not work if a maintainer is active on some packages but not on some other, and only the package that is effectively unmaintained needs salvaging. - there are other kinds of processes for maintainers that are actively hostile to Debian - Is there a taboo for overtaking packages? Are there blockers to the adoption of the salvaging process? → feels like this may never be in Debian Policy → proposal is to put it devref, where NMU guidelines are. certainly not perfect solution, but maybe good enough? Vagueness (see gregoa's proposal on -devel) could be a good thing, and the worst that can happen if someone does a bad call on salvaging is that an ITS bug gets opened and closed, and something that was unclear gets documented. The number of months and so on that are currently in the proposal are still useful to empower a new maintainer to make the call without fear, and could be put as an example reference in the wiki, rather than in the devref Next steps ========== - propose a patch to devref :) Things we need to talk about ============================ - What do you think of the timings? - How to establish the process: - Put it into dev-ref - OK by delegates (leader, DAM, ftp, ... ) - GR? Background ========== Subject: Let's start salvaging packages! Dear fellow Debianites, tl;dr: Let's bring the package salvage process discussed some years earlier to life! There will be a BoF at DebConf18 Thursday, August 2nd 11:00 in Room Xueshan [a] for dicussion and fine tuning. (We will likely have video coverage.) I'm sending out our proposal draft already now so you will be able to come well-prepared to the to the BoF, as we want to have as much time as possible for the discussion. There will be a also a gobby document for the BoF [b]. [a] https://debconf18.debconf.org/talks/149-lets-start-salvaging-packages/ [b] gobby infinote://gobby.debian.org/debconf18/bof/lets-start-salvaging-packages Why is a salvaging process necessary? ===================================== Most of the packages within Debian are well maintained and you -- our maintainers do a tremendous job to keep it that way. Let me start by saying a big thanks for that! However, we have to be honest: we've got also quite some packages which are not so well cared for. For these packages, unpackaged upstream versions and unreplied bugs are often seen. As a result those packages are not quite up to the quality level our users expect when using Debian. I'm not talking about orphaned packages, as we have processes for those, but about packages that have fallen through the gaps, especially when the maintainer is otherwise active. As a project, we do not have effective processes to deal with such "neglected" packages. Even if someone shows up wanting to improve such a package, they are usually not entitled to do so without explicit consent of the current maintainer, which might be difficult to obtain. Salvaging Process Proposal ========================== Salvaging a package ------------------- Salvaging is the process by which, one attempts to save a package that, while not officially orphaned, appear poorly maintained or completely unmaintained. This is a weaker and faster procedure than orphaning a package officially through powers of the MIA team. Salvaging a package is not meant to replace MIA handling, and in contrast to it, it does not comment about the overall activity of a maintainer. Instead, it handles a package maintainership transition for a single package only, leaving any other package or Debian membership or upload rights (when applicable) untouched. Reasons to salvage a package ---------------------------- A package is eligible for salvaging if it is in clear need of some love and care, i.e. there are open bugs, missing upstream releases, or there is work needed from a quality-assurance perspective; AND there is the need to upload the package to deal with these issues; AND at least one of these criteria applies: * There is no visible activity regarding the package [c] for /six months/, OR * A previous NMU was not acknowledged, and a bug justifying another NMU is pending for /one month/ [c,d], OR * The last upload was an NMU and there was no maintainer upload within /one year/, OR * Bugs exist for more than one major missing upstream version and the first bug is older than /one year/, OR * The package blocks a sourceful transition for /six months/ after a transition bug was filed against the package in question. Procedure to salvage a package ------------------------------ If the criteria described above are fulfilled, anyone interested can start the following salvage procedure. 1) A bug with severity "important" against the package in question must be filed, expressing the intent to take over maintainership of the package. The reporter may also offer to only take co-maintenance of the package. When filing the bug, all maintainers (incl. Team) and uploaders should be put explicitly in X-Debuggs-CC. (Note if the maintainer(s) seems to be generally inactive, it is also a good idea to inform the MIA team in this step by X-Debbugs-CC'ing mia@qa.debian.org ) 2) The maintainer, any current uploader or any member of the associated packaging team of the package in question may object publicly in response to the bug filed within 21 days, and this terminates the salvaging process. The current maintainers may also agree to the intent to salvage a package by filing a (signed) public response to the bug. The maintainer also might offer the reporter co-maintainership instead. On team maintained packages, the associated team might also send out an signed agreement notice to the reporter, inviting him to become Co-Maintainer of the package if the team believes that this would beneficial for the package and the the current maintainer does not object to it. In those three cases, a new package can be uploaded immediately by the new (co-)maintainer(s). 3) The upload replacing the former maintainers of the package can be made can be prepared already after 21 days, but needs to go to DELAYED/7. The salvage bug should be closed by the upload and an nmudiff sent to the bug. The nmudiff should also explictly CC the maintainer, the packaging team and all uploaders. [c] Level of activity should be defined in favor of the maintainer if in doubt. A maintainer may ask for help or welcome a NMU. This counts as activity with respect to salvage criteria. If a package lacks uploads, there is no visible bug triaging, and - if applicable - the source package's VCS does not show commits this is an indication, that the package is not well maintained. [d] A NMU is automatically ACKED if there is a subsequent upload of the maintainer including the content/fixes of the NMU. Thoughts behind the proposal ============================ The salvaging idea was written by Arno Töll in 2012 [e] and have been mentioned during the "if you love a package let it go" BoF held by David Bremner and myself at last years DebConf [f], and the audience at the BoF suggested that we should give this idea a spin. I've talked already with several people @DebCamp18 and everyone so far encouraged me to bring this idea forward. The idea is to create a procedure based on _clear_ rules defining when it will be acceptable to salvage a package and bring it back into maintainance by a new interested contributor -- and when it is not. The rules should be balanced to protect the interests of the current maintainer, but on the other hand they should not make it too hard to actually take over a package if it is indeed neglected and needs love. Clear rules are important for several reasons: - It will ensure that everyone knows when it is allowed to salvage a package. - This will lower the (mental) barrier to salvage a package, maybe even attracting new contributors. Teams will also be able to recruit new contributors. - The rules puts an emphasis on communication -- to help avoid misunderstandings. - The rules will protect the potential contributor (new or otherwise) to Debian, to avoid that someone who came to give a helping hand is shouted at. As Arno wrote in the original thread: "I think the most important rationale is to get people not to be afraid to take over packages anymore, if their intentions are meant well." - They also protect a maintainer from finding his packages unreasonably hijacked by someone else. One particularly important issue that could be (partially) addressed by salvaging is the following. Outdated dependencies might make it impossible to update a certain package to the latest version. This is not only bad because now we have two outdated packages, but also easily can generated frustration that does even more damage: Lately I was handling a MIA process where the one being MIA cited exactly this as an reason why he threw in the towel and ceased activities within Debian. Another aspect I want to share with you is, during my MIA work, I noticed that this might help when someone reporting someone MIA is doing so because they are interested in a package. Currently we must say "please wait around half a year" even on cases were no one really expects a response from the former maintainer. With the proposed process we can encourage them to take over the package accordingly and have it maintained well again. Making the reporter wait 1/2 year makes it unlikely they will take over a package. The severity of the "intend to salvage" bug is intentionally non-RC. While RC bugs would have a better visibility, package auto-removals could kick in and remove the package in question from testing. If a package is team-maintained, the team should also be able to veto a request, but should also be able to pave the way for a new maintainership, but not against the expressed will of the current maintainer. The team is also encouraged to invite the reporter to join the team. [e] https://lists.debian.org/debian-devel/2012/09/msg00654.html [f] https://gobby.debian.org/export/debconf17/bof/if_you_love_a_package_let_it_go Why NMUs and MIA aren't the solution ==================================== You might say that we have an NMU process and an MIA process for this, but both are not the silver bullet for this situations. Granted, the NMU process is great to handle urgent problems, to get a package in a (frankly, often barely) suitable state for the next release, but it has severe limitations: New upstream versions are out of scope, not-as-important-but-still-annoying bugs, etc… But even if those problems could be fixed by NMUs this is not very sustainable. Especially if packages are solely NMU-maintained years after years, release after release. As often those NMUs are done by the very same people I think it is realistic to assume that those would be a candiate for taking over the package and maybe do so if it would be easy for them. This would serve for sure also as some appreciation for their work and also is an nice opportunity to acquire new contributors to the project. On the other side, the MIA process is not a package based process. We only follow up if someone noticed that a person is no longer active. IOW, People which are mostly taking care of their packages are not in the scope of the MIA team. Additionally, the MIA process is a lengthy one. Even if everything looks like that the person is indeed MIA, and they do reply to our pings at all, it will take *months* until we can orphan the package. If the one notifying us is interested in taking over the package, we have to tell him to come back months later, even if the package has not been touched for years. (In my experience, telling someone to wait for so long will likely lead to another opportunity lost to get it back into maintainance.) On the other hand, even if the MIA candidate is answering it still happens too often that there will be lots of well-intentioned words but zero action. Frequently Asked (Anticipated) Questions ======================================== Q: I'm not convinced that this is a problem. Can you show me some examples. A: I tried hard to come up with examples, but I really want to avoid any impression of finger pointing and it is hard to name specific examples without that. But I'm pretty sure that you have encountered sloppiliy/bad/un- maintained packages, maybe even wanted to improve them but then figured out that this would have been an hijack. Q: Isn't it _MY_ package, so I can do and not do as I please? A: Sure, Debian has a tradition of strong ownership of packages, so traditionally you have the say on the package. This proposal does not change that, so you can still do anything you want with your package. But remember that maintaining a packaging also brings responsibilities it and that means that you want to want the best for it. Actually, I hope you want the $best, whatever $best is, _for the Debian project_. Q: Don't we have the MIA process for this? A: As I elaborated above already, the MIA process can only help if a persons disappears completely. The MIA team cannot work on a per-package basis, because of limited capacity and also because it is out of the scope of the team. And especially in cases where the maintainer is active overall there might be still packages that are deprived of love and those won't be helped by the MIA procedure. Q: Don't we have the NMU process for this? Q: I'm on the LowNMU page. A: NMU has some really limited scope, it needs to fix at least "important" bugs and won't really help e.g with new upstream versions. It will not get a new maintainer on board, which would especially boost a long neglected package. It is also difficult for new contributors to get packages NMUed, especially for non-RC bugs. Q: But I did a new upstream version as NMU? A: I did that too, and it is possible to do. But then you also need to be prepared to take the pushback from this and not everyone has the thick skin required to survive a possible outbreak of a heated discussion. IOW, The proposal adds some procedural safety for the salvager as well. But it also underlines the importance protecting maintainer from hijacks. Q: My packages are all team maintained, so this process is unnecessary as the team will take care of my neglected packages. A: A team can help to collaboratively maintain packages, but that does not mean that the team is capable to work on all the team's packages. But frankly, by just listing a team as maintainer makes it not magically maintained. Q: Theres the "LowThresholdAdoption" [g] list. Wouldn't that help? A: Personally I don't think so: Those on the list are likely already the people how anyway take good care about their packages but not those that simply lost interest. Q: Wouldn't be the ctte another possibilty? A: The ctte is another possiblity, but as this process is not lightweight at all, I think it isnot suitable to solve this problem, due to scalability and because the ctte process is designed to be a last-resort possiblity. Many people also do not have the time and energy to deal with a tech ctte bug. Q: How long will this process take? A: In total 28 days. After the salvaging bug is filed, the reporter has to wait 21 days for a reply, and the package must sit for 7 days in the DELAYED queue. Q: I like the proposal. How to implement it? A: Help discussing it. Help implementing it. Come to the BoF. [g] https://wiki.debian.org/LowThresholdAdoption