FTBFS Bug Filing and Handling proposal

[Matt Domsch]

A proposal for consideration.
http://fedoraproject.org/wiki/MattDomsch/FTBFS

Proposal

This is only a proposal. It will be edited before being approved.
Feedback requested.

FTBFS (Fails To Build From Source)

In the interest of keeping Fedora as a self-hosted distribution
(meaning you can use Fedora version Z to build Fedora version Z from
source RPMs), MattDomsch regularly runs a full rebuild of the
"rawhide" tree, building rawhide with rawhide. This catches a number
of packages that no longer build, and need developer attention. The
results of each run are presently mailed to each failing package's
owner and cc: list (as noted in the package database), and sent to
fedora-devel-list.

In the interest of tracking these failures, new bugs for each failing
package will be filed in Bugzilla. These bugs will all block a blocker
bug, alias "FTBFS". Included in these bugs will be the root.log and
build.log from mock. These bugs should start life in a state of
ASSIGNED, since they are by definition pre-triaged.

On subsequent runs to the first, a check will be made that there is
not already a bug that's blocking FTBFS for the package in
question. If there is, a comment will be made in the existing bug. If
there's not, a new bug will be filed against the package.

Challenges

    * avoiding false positives. It somewhat often happens that a whole
      class of failures are due to either build system
      mis-configuration, mirrors being slightly out of sync.
    * bugs in required packages. If glibc is broken on a particular
      day, it can affect a large number of package builds. It's most
      appropriate to file a single bug against glibc in this case
      rather than many bugs against each package that hit the
      bug. Unfortunately, figuring this out requires human
      intervention.
         1. Being that this is a monthly event, I think that simple
      sanity checking is really all that's required here - nothing
      fancy. Rebuild and filing should be two separate phases, so that
      these issues can be caught. 

Proposal

    * File bugs, once for each package.
    * Block FTBFS
    * FTBFS blocks Target tracker for next release
    * attach root.log and build.log from each architecture that has failed.
    * Fedora version = 'rawhide'
    * Follow up with public shame on bugs >30 days???
    * run monthly



Feedback to this list, and/or edit the wiki directly.

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux