Dear Tobi,
> 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. Just as a point of order, I would just like to be sure that enough notes get taken at > > 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 > ========================== > > <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 > m...@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. > > </proposal> > > 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 > > Thanks for reading all the text, > > -- > tobi > with lots of kudos to bremner, spwhitton and lamby for their valuable > input and co-editing. > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
