MIA means "Missing in Action". When a project is built by volunteers, as
is the case with most Linux distributions, sometimes packages with bugs
linger and are not fixed for long periods of time. The developer is MIA.
There are many reasons that a developer might have for not taking care of
their packages as promised. There will be times with the demands of work,
school, family, or whatever will take precedence over volunteer work. In
an ideal case the person will tell someone that they won't be around for a
while. They might even find someone else to take over for them while they
are gone. All too often though they don't do anything at all and thereby
Both Debian and Fedora have made proposals for dealing with MIA developers
this week so we wanted to take a closer look at how these projects are
dealing with this problem. Keep in mind that Fedora and Debian are
different projects, with different goals. Fedora is fast paced, with a
release every six months. They can't allow buggy packages to linger for
long. Debian's release cycle is long, but they have large number of
packages to maintain and a large number of developers to keep track of.
Debian's Bits from the MIA team goes beyond
a proposal and outlines what is now the current policy for dealing with MIA
maintainers. The MIA team met recently in Spain to flesh out the details.
The MIA team is a small group of people who are tasked with identifying and
attempting to contact maintainers who no longer seem to be active.
Team members have access to several MIA scripts which can be used to
identify unresponsive maintainers. "The most important tool is
"mia-query" where you can see the history from the person, which packages
he/she maintains and the last-activity." The process is lengthy,
allowing 15 days after each attempted contact before proceeding to the next
stage. After sixty days the maintainer's packages will be orphaned so that
some other maintainer might adopt them. Only after ninety days will the
person be subject to removal from the keyring, if they are Debian
Developers (DD) or Debian Maintainers (DM). For packages that are team
maintained the missing person will be removed from the
Uploaders/Maintainers-field after sixty days.
is still the initial stages. The idea is to automate the process as much
as possible. "This proposal aims to create a framework for
automating the detection and processing of MIA maintainers. The framework
will touch upon bugzilla, pkgdb, koji, and various automated QA efforts. It
will tie into the (new) policy of automatically cleaning up orphans created
during a release at the start of the next development cycle."
A scheduled process will query bugzilla, looking for a certain class of
bugs. If the maintainer reaction time meets a certain criteria, the
maintainer will be marked as MIA.
How these bugs are identified in Bugzilla remains to be solved. Several
automated QA tasks identified so far include: broken dependencies tests,
rebuild tests, package/file conflict tests, and upgrade path violation
tests. "Most of these tasks will need to grow the ability to file
bugs for the issues discovered, with the logic to prevent multiple filings
for the same issue. As stated above, a keyword or a flag or something will
be added to the bug so that it can be easily identified at a later
Many details remain in this proposal, such as the particular allotment of
times for responses, the method that will be used in bugzilla to mark a bug
for MIA detection, who will make use of that method, who will work on the
detection/processing tool, who will be notified of a maintainer going MIA,
whether all packages owned by the MIA maintainer get orphaned, and so on.
A truly automated system for identifying MIA maintainers will likely be of
interest to other projects, especially if it can be adapted to other
to post comments)