Overview
Problem Space
With the ever growing number of Fedora contributors and packages it is becoming increasingly more and more difficult to detect when a maintainer has moved on, or is otherwise "Missing In Action". This leads to a lot of packages which are no longer maintained but aren't marked as orphans as they should be. This creates many points of frustration within the user and developer communities as bugs filed go unanswered.
Scope
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.
Active Ingredients
The main active ingredient to this proposal is the creation of a scheduled process that will investigate bugzilla for a specific class of bugs, determine the maintainer reaction time (if any) and if criteria is met mark the maintainer as MIA.
Bugzilla
A specific class of bugs will be added to bugzilla. This may be controlled via a keyword, a flag, or some other method. These bugs are filed by automated QA tasks which are pre-approved by FESCo as being appropriate criteria for automated MIA detection. The time between the bug being filed and a maintainer/co-maintainer responding will be considered the response time.
Automated QA Tasks
The automated QA tasks that can be used as bugzilla entry points could include:
- Automated broken dependencies tests (currently done by rawhide scripts)
- Automated rebuild tests (currently done by Matt Domsch)
- Automated package/file conflict tests (not yet implemented)
- Automated upgrade path violation tests (currently done by ...?)
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.
Automated Detection/Processing Script
This describes a high overview of what the detection/processing script would look like.
Detection
This script will be used to discover the previously mentioned bugs. It will use a dump of the non-orphaned packages from pkgdb as the list of packages to query. It will determine the reaction time, if any, and if the timeout is longer than that which is allowed by the MIA policy (currently known as the AWOL policy) an email will be sent to the maintainer/co-maintainers of the package in question, as well as the fedora-devel-list. A database may be used as well to keep track of whom has been marked MIA and for which packages. Upon subsequent runs of the script if a maintainer triggers as MIA a db lookup will be done to determine if the maintainer has already been contacted, and has been given the allowed allotment of time to respond. If the allotment has been consumed without response, the script will kick in to processing mode.
Processing
Once a maintainer has been deemed MIA, a number of things will happen. In no particular order:
- Maintainer announced as MIA to:
- maintainer
- fedora-devel-list
- co-maintainers of all packages owned by MIA maintainer
- maintainers of all packages MIA maintainer was a co-maintainer for
- All packages owned by MIA maintainer marked as orphan in packagedb
- Ownership of said packages synced with Koji
- All NEW bugs for packages owned by MIA maintainer re-assigned to orphan
- All OPEN/MODIFIED/NEEDINFO/and otherwise not closed bugs commented on indicating that MIA maintainer is in fact MIA
- Detection DB updated to indicate maintainer was marked MIA and associated packages marked orphaned.
Discussion Points
A number of things in the above overview could use some discussion.
- Re-evaluation of current AWOL policy, in particular the allotment of times for responses.
- What method will be used in bugzilla to mark a bug for MIA detection
- Who and what can make use of said method
- Ongoing additions/removals of who and whats.
- Who is going to work on the detection/processing tool
- Who all gets notified of a maintainer going MIA
- Whether all packages owned by MIA maintainer get orphaned
- What all bugs to touch and how to touch them