Re: Let's start salvaging packages!
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
> 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.
>
> </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
`. `'` lamby@debian.org / chris-lamb.co.uk
`-
Reply to: