FTBFS Bug Filing and Handling proposal
Matt Domsch
Matt_Domsch at dell.com
Tue Apr 1 13:43:25 UTC 2008
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
More information about the fedora-devel-list
mailing list