#11 Add the new FTBFS and FTI policy
Merged 5 years ago by zbyszek. Opened 5 years ago by churchyard.
fesco/ churchyard/fesco-docs ftbfs_fti  into  master

@@ -0,0 +1,169 @@ 

+ # Fails to build from source, Fails to install

+ :toc:


+ This page describes *the policy for packages that no longer build or install* and

+ need developer attention.


+ The schedule for most releases of Fedora includes a mass rebuild (e.g.

+ https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild[Fedora 27 Mass Rebuild],

+ https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild[Fedora 28 Mass Rebuild]) to update the

+ packages with new features of the compiler, packaging, build flags, etc.

+ This serves as a convenient opportunity to detect all packages which no

+ longer build properly.


+ ## Glossary


+ FTBFS:: Fails To Build From Sources

+ FTI:: Fails To Install (usually due to broken dependencies)



+ ## Package Removal for Long-standing FTBFS and FTI bugs


+ Packages which fail to build or fail to install will be orphaned and/or

+ retired after a period of time.


+ 1.  If a package *fails to build from sources* or *fails to install*,

+     any concerned party can *file a bug* in Bugzilla blocking a FTBFS/FTI

+     tracker, providing information about the failure.

+     * A bug about build failure needs to block the FTBFS tracker for the

+       appropriate release, eg. F30FTBFS for Fedora 30, see list below.

+     * A bug about installation failure needs to block the FTI tracker for

+       the appropriate release, eg. F30FTI for Fedora 30, see list below.

+     * One bug can block multiple trackers if convenient. Reporters are

+       encouraged to search for duplicates first.

+ 2.  Maintainers should either fix and close the bug or acknowledge that

+     they are working on a solution by setting the state to ASSIGNED.

+ 3.  If an FTBFS or FTI bug remains in the NEW state for at least *1

+     week*, any concerned party can set a *NEEDINFO* for the maintainer to

+     respond and send an *e-mail reminder* with the Bugzilla link to

+     `+<component_name>-maintainers@fedoraproject.org+`, cc'ing the

+     https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/[devel

+     mailing list] (so there is a public record) and commenting on the bug

+     about doing so.

+ 4.  If the bug remains in NEW state for at least another 3 weeks after

+     the NEEDINFO and e-mail (= at least for *4 weeks* in total), any concerned party

+     can send *another comment and e-mail* (as in the previous point).

+ 5.  If the bug remains in NEW state for at least another 4 weeks after

+     the second e-mail and comment (= at least *8 weeks* in total), the package

+     will be *orphaned*. Orphaning can be requested via a releng issue.

+ 6.  The normal

+     https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers[Orphaned

+     package that needs new maintainers procedure] will be followed for the

+     packages orphaned in this way, leading to their *retirement* if nobody

+     adopts them.

+ 7.  A week before the *mass branching*, any packages which still have

+     open FTBFS bugs from the previous release will be *retired*. This can be

+     requested via a releng issue.

+ 8.  A week before the scheduled *beta freeze*, any packages which have

+     open FTI bugs in the NEW state with at least 8 weekly reminders will

+     be** retired** from the relevant release and rawhide (in addition to

+     being orphaned). (Releng ticket for this needs to be opened at least a

+     week before the freeze, but can be opened sooner.)

+ 9.  The previous point repeats for the *final freeze*.


+ (Effectively, packages will be retired after 14 weeks or sooner if there

+ is no maintainer response and the package is orphaned, or after 6½

+ months if the maintainer responds to FTBFS but the bug is not fixed.)


+ When releng performs the

+ https://docs.pagure.org/releng/sop_mass_rebuild.html[mass rebuild],

+ releng opens FTBFS bugs for any packages which fail to build. Anyone can

+ send the weekly reminders and request packages to be orphaned/retired –

+ in other words, the procedure can be applied manually.

+ At any point, releng can automate any steps mentioned above,

+ but this is not required.


+ Anytime a releng ticket is open, please cross reference it from the bug

+ report.



+ ## Tracking bugs


+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=440169[generic

+ FTBFS blocker bug]

+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=440169&hide_resolved=1[F9FTBFS]

+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=463452&hide_resolved=1[F10FTBFS]

+ * F11 was handled by Release Engineering, no FTBFS bugs were filed.

+ http://jkeating.fedorapeople.org/needed-f11-rebuilds.html

+ (https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild[Fedora 11 Mass Rebuild])

+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=511348&hide_resolved=1[F12FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild[Fedora 12 Mass Rebuild])

+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=538681&hide_resolved=1[F13FTBFS]

+ ** https://bugzilla.redhat.com/showdependencytree.cgi?id=564245&hide_resolved=1[F13FTBFS

+ due to] Features/ChangeInImplicitDSOLinking

+ * https://bugzilla.redhat.com/show_bug.cgi?id=596849[F14FTBFS]

+ * https://bugzilla.redhat.com/show_bug.cgi?id=659965[F15FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild[Fedora 15 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=713919[F16FTBFS]

+ * https://bugzilla.redhat.com/show_bug.cgi?id=817273[F17FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild[Fedora 17 Mass Rebuild])

+ * There seem to be no FTBFS bugs reported for Fedora 18, list of failed

+ builds from the mass rebuild:

+ http://fedorapeople.org/~ausil/f18-failures.html

+ (https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild[Fedora 18 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=913825[F19FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild[Fedora 19 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=991858[F20FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild[Fedora 20 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1105908[F21FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild[Fedora 21 Mass Rebuild])

+ * F22?

+ * F23? (https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild[Fedora 23 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1305208[F24FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild[Fedora 24 Mass Rebuild])

+ * No mass rebuild in F25

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1423041[F26FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild[Fedora 26 Mass Rebuild])

+ * F27? (https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild[Fedora 27 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1555378[F28FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild[Fedora 28 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1602938[F29FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild[Fedora 29 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1674516[F30FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild[Fedora 30 Mass Rebuild])


+ ## What to do if you get a FTBFS bug?


+ * Read the logs. Each FTBFS bug should have the build logs attached.

+ * If the build of your package fails due to a bug in *your package*:


+ 1.  Fix the problems uncovered and commit the changes.

+ 2.  Build the package. The fixed package will land in rawhide, generally

+ the next day. If branching has already occurred, also fix the build in

+ branched.

+ 3.  If the build succeeds, close the bug as CLOSED: RAWHIDE, and include

+ the package version number in the _Fixed In Version_ field.

+     Here is a command line template for powerusers:

+     `+bugzilla modify --close RAWHIDE <bug-number> --comment

+     'Built successfully in rawhide' -F <package-nevr>+`

+ 4.  If branching already occurred, but bodhi hasn't been activated yet,

+ also build the package in branched.

+ 5.  If bodhi has already been activated for branched, also make an

+ update. An update should be made even if branched has already been

+ released.


+ * If the build of your package fails due to a bug in *another package*

+ (such as a compiler bug or missing dependency):


+ 1.  Find an existing bug for that package describing the problem. Set

+ your bug to "Depends on" that other bug. Do not change the component of

+ your bug to the other package, or you will get more FTBFS bugs created

+ against you.

+ 2.  When that other bug is closed, you'll get an email from bugzilla as

+ usual. Rebuild your package using a koji scratch build, to verify it

+ builds cleanly again. Proceed according to points 2-5 above.


+ * If the package is no longer useful to the Fedora project, it should be

+ retired.

+ See https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life[How

+ to remove a package at end of life].


+ In all cases, if you close an FTBFS bug as a duplicate of another bug,

+ please make the other bug to block the right FTBFS tracking bugs. This

+ way the bug left open will appear in the FTBFS reports properly.


+ ## See also


+ * FESCo ticket updating this policy: https://pagure.io/fesco/issue/2109

+ * releng docs:

+ https://docs.pagure.org/releng/sop_deprecate_ftbfs_packages.html

no initial comment

I'll update the tracker alias and add links once https://pagure.io/releng/issue/8275 is done.

This sentence is not very clear. Maybe "At any point, releng can automate any steps mentioned above, but this is not required."

In the fixed field maybe? Also, I'd include the relevant cmdline for power users:

bugzilla modify --close RAWHIDE <bug-number> --comment 'Built successfully in rawhide' -F <packager>-<nevr>

Well the instructions are only for FTBFS. If we want a similar section for FTI, we should draft it from scratch.

1 new commit added

  • Nitpicks
5 years ago

I've committed (most of) your proposed changes.

Pull-Request has been merged by zbyszek

5 years ago