When developers go MIA [LWN.net]

By Rebecca Sobol
December 12, 2007

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 become MIA.

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.

Fedora's proposal 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 time."

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 infrastructures.

(Log in to post comments)