Hi Andreas, thanks for trying this out. I think laptop-detect is actually a useful example of where we need to distinguish two things.
The maintainer appears to fit the narrow class of Debian Contributors for which we intended the simplified MIA handling. However, laptop-detect appears to be an important package in the archive, with a Popcon count of more than 250,000 indicating that it is installed very widely. For packages like this, I think it is important to first try to reach the maintainer and establish whether they are still interested in maintaining it. In such cases, the regular MIA process should normally be the default. This is also why the MIA Team should be contacted before taking action in cases like this. DELAYED/15 is a useful safety mechanism for an upload, but it is not a substitute for asking MIA when it is unclear whether a case falls within the intended procedure or what the appropriate action is. Uploading first and relying on DELAYED to give MIA an opportunity to object effectively puts a deadline on the MIA Team to notice and review the action. That reverses the intended process and creates exactly the kind of additional workload and time pressure that the simplified process is meant to avoid. There is also a more subtle reason why I would prefer the orphaning bug not to be filed before we have made that assessment: filing such a bug already creates a public expectation about the outcome. Where the situation is reasonably clear, this is a compromise we may accept as part of the simplified process; otherwise, one of the principles of the MIA Team's work is to avoid unnecessarily prejudging cases or putting blame on the person involved, and to handle such situations as discreetly as practical. For the same reason, please do not raise questions about an individual's maintenance status on public mailing lists. So I'd suggest holding off on the orphaning upload/bug for now and letting us look at this particular case. Regarding the documentation: I agree that documenting this more permanently would be useful, but I'd consider that step 2. First we should establish the process in practice, iron out its edges and ensure that there is project consensus before we documenting it appropriately. As for molly-guard, I would for now leave this to its existing Uploaders. Keeping the Uploaders field accurate is part of maintaining the package, so there is no need to take action merely because an outdated entry has been noticed, especially when several of the other listed Uploaders are known to be active. -- tobi (for the MIA Team) On Tue, Aug 04, 2026 at 07:52:16AM +0200, Andreas Tille wrote: > Hi Tobias, > > thank you for this proposal. > > I believe I have found a package that appears to fit the criteria you > describe. To make sure I have understood the intended procedure > correctly, I have done a QA upload of laptop-detect to DELAYED/15 and > filed the corresponding orphaning bug (#1143551). > > Using DELAYED/15 should leave sufficient time for anyone to point out if > I have misunderstood or misinterpreted the announcement before the > upload is accepted. > > I think it would make sense to also announce the text below on > debian-devel-announce and document it in the Developer's Reference. > > I also wonder whether you might consider opening a bug to update the > list of uploaders of the package molly-guard as task for any DD or > remains the task of the MIA team. > > Kind regards > Andreas. > > > Am Fri, Jul 31, 2026 at 08:11:24PM +0200 schrieb Tobias Frost: > > 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 > > > > -- > https://fam-tille.de
signature.asc
Description: PGP signature
