Re: FTBFS Bug Filing and Handling proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matt Domsch wrote:
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


+1,

One note the public part of the script should check if the already filed bug is blocking on some other bug before doing the public shaming.

I've been busy failing my FTBFS packages today and 5 of them fail to build due to an ImageMagick bug (which I'm currently hunting down).

Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux