Hi, I'd like to share a small change in how the MIA team has recently been handling a specific class of reports, but more importantly, to encourage a broader QA mindset.
The MIA process serves both security and QA purposes, like quality and maintainability of the archive. It is an useful tool, but like any tool, it is not the right one for every situation. A recurring pattern we've seen is reports concerning Debian Contributors who were active only for a relatively short period, contributed to only a small number of packages, and have shown no Debian activity for many years. Before investing effort into finding a new maintainer - or establishing whether the current one is MIA - it can be worth evaluating whether the package still provides sufficient value to Debian. Removing a package that no longer serves a useful purpose is just as much a QA improvement as finding a new maintainer for one that does. There is no single criterion that answers this question. However, a combination of factors can indicate that proposing removal deserves serious consideration. Examples include: - very low package usage (e.g. popcon), - no upstream activity for an extended period, - software that has become obsolete or has been superseded, - packages where the Debian maintainer was also effectively the upstream maintainer, and upstream has ceased for many years, - being largely isolated within the archive (for example, no reverse dependencies beyond closely related companion packages), None of these factors should be interpreted in isolation. Niche packages may naturally have low popcon numbers, upstreams sometimes become stable rather than inactive, and contributors do occasionally return after a long absence. These are indicators intended to help guide judgement. If the situation already provides sufficient indication that action is needed, for example based on several of the indicators mentioned above, it may be more effective to first evaluate whether the affected packages should remain in Debian. Removal can be a better QA outcome than finding a new maintainer. If the packages should remain, then salvage or orphaning are possible next actions. Where the appropriate course of action is already reasonably clear, you may choose to act accordingly without involving the MIA team, though it remains the appropriate point of contact whenever the right course of action is less clear. The above recommendation is intended for project members with sufficient context to make such QA assessments; it is not intended as a general recommendation to bypass or replace the MIA process. The approach described here applies only to the narrow class of reasonably to be assumed MIA Debian Contributors described above. Other cases should continue to follow the existing MIA procedures. Rather, it is a reminder that the MIA process is a means to improve QA, not an end in itself. Accordingly, the MIA team may use a simplified process exclusively for this narrow class of reports. For these reports, running a full MIA procedure may not be the best use of the limited MIA team resources as the additional investigation required can be significant, while an incorrect assumption can usually be easily corrected. If the contributor is still interested in maintaining the packages, they can simply reply or close the bugs. Therefore instead of initiating the regular MIA procedure, we may directly orphan the affected packages or file "Remove from Uploaders" bugs while informing the contributor of the actio taken. This allows the MIA team to focus its effort on cases where the process provides more value. -- For the MIA team, with thanks to my fellow MIA team members Paul Gevers and Nilesh Patra for their reviews and suggestions, tobi
signature.asc
Description: PGP signature
