Anaconda/AnacondaBugWorkflow

Fedora Anaconda Bug Workflow

Background

Fedora anaconda bugs do not follow the default workflow. The flow of anaconda bugs makes greater use of the natural language meaning of bug states as it relates to having multiple developers, as well as discarding a few states which are not helpful. Using these guidelines will enable contributors to better know what they can expect is being done on bugs they have filed.

Note: Like all bugs, anaconda bugs are generally dealt with in the order in which they arrive, but fix or hardware complexity can cause lower-numbered bugs to sit around longer than their higher-numbered counterparts.

Overview

Fedora Anaconda uses the NEW, ASSIGNED, MODIFIED, and CLOSED statuses, as well as the CLOSED sub-statuses of NOTABUG, WONTFIX, DEFERRED, WORKSFORME, RAWHIDE, CANTFIX, INSUFFICIENT_DATA, CURRENTRELEASE, and DUPLICATE. It also uses the needinfo flag.

NEW

When a bug is filed, it automagically starts out in NEW, and will either remain there or change state. If a bug remains in NEW, it means that an anaconda developer has not specifically been assigned to fix the bug. Unlike the more general workflow, it says nothing about whether the bug provides sufficient information to be fixed.

If the bug is going to change state, it should do so according to the guidelines laid out in the following sections.

Needinfo

If the bug is missing vital information that is needed to fix it, the needinfo flag should be attached and the information should be requested.

It is not always clear what the necessary information might be, so general guidelines are as follows:

If the report mentions a traceback or exception report but one is not provided, /tmp/anacdump.txt should be attached. If the reporter does not have an anacdump.txt file, /tmp/anaconda.log should be attached instead.

If the bug is a storage bug, /tmp/storage.log should be attached.

If the bug is a packaging problem, /tmp/install.log should be attached.

If the bug is with bootloader, a filesystem not being created, or an external program, /tmp/program.log should be attached.

Due to the nature of anaconda as an installer, more time is provided to bugs in needinfo than might be common otherwise. Unless a developer says otherwise, bugs should be allowed to stay in needinfo for three months before being CLOSED INSUFFICIENT_DATA.

ASSIGNED

If a bug is in ASSIGNED correctly, it means that the proper developer to fix the bug has been selected and it is in the queue of actionable items. If a bug is in ASSIGNED but the assignee is anaconda-maint-list, the bug should either be moved back to NEW or the proper developer should be selected.

When a bug correctly moves into ASSIGNED, anaconda-maint-list@redhat.com should be removed from the CC list. Because of what ASSIGNED means, this cuts down on needless list-wide emails on bugs that no longer need general attention.

General guidelines for who should be working on a bug are:

• clumens: package installation, general exception processing
• pjones: initrd, bootloader, booty, multipath
• katzj: livecd, package installation
• dcantrell: networking, Network Manager, s390, virt, livecd
• dlehman: encryption, general partitioning
• hdegoede: dmraid
• rvykydal: RAID
• jgranado: parted, RAID, LVM

MODIFIED

This state should be used when a developer has made a fix which has not yet been tested in rawhide. Bugs which move into MODIFIED cannot be tested until anaconda has been rebuilt, but once tested, should move back into NEW or ASSIGNED (whichever is correct) if the bug is still present, and into CLOSED RAWHIDE if the bug is fixed.

If the reported bug is fixed but a new bug is encountered during testing, the original report should be CLOSED RAWHIDE and a new bug should be opened detailing the new problem.

Bugs will often skip the MODIFIED step when a developer is reasonably sure that the fix will solve the problem, and that anaconda will be rebuilt soon. In addition, bugs which have been in MODIFIED for one month with no indication that the problem continues to exist may be moved into CLOSED RAWHIDE.

CLOSED

Bugs may move into CLOSED for a variety of reasons, fixed or not. A bug which has been confirmed fixed should of course be closed out, as should ones that will not be fixed or that are duplicates of other reports.

• If a bug has been identified as a duplicate of another bug report, it should be closed as a DUPLICATE. Most of the time, the higher numbered bug is closed against the lower numbered bug, but in cases where the newer bug has more information it can go the other way around. When in doubt about whether a bug is a dupe or not, ask the relevant developer.
• When a bug works in the current version of rawhide, it should be closed as RAWHIDE.
• When a bug has already been fixed in the latest release (such as a bug filed against F10 that is not a bug in F11), the report should be closed as CURRENTRELEASE.
• If a bug has been in needinfo for at least three months with no answer from the reporter, it should be closed as INSUFFICIENT_DATA. Sometimes bugs will get closed in less than three months, especially if a big rewrite was done on that part of the code, but that is a developer's call.
• Bugs where the reporter has indicated that they are unable (or unwilling) to provide the requested information should also be closed as INSUFFICIENT_DATA.
• Reports which are a result of user error or an intended functioning of anaconda should be closed as NOTABUG. Unless it is obvious that the reporter's computer exploded, a developer should be consulted before closing as NOTABUG.
• CANTFIX, WONTFIX, and WORKSFORME should be set by the developers only. Non-developers should only send bugs to these categories if a developer has already closed a bug into one, and the reporter (or somebody else, but not the developer) has reopened the bug.
• If a triager is able to attempt to reproduce the bug exactly as described and cannot, it is a good idea to add a comment to this effect - but even then, the bug should not be closed as WORKSFORME.
• DEFERRED is used for reports which contain a legitimate bug or feature request, but that will not be fixed in the next release. This should also only be set by a developer.
• UPSTREAM, ERRATA, and NEXTRELEASE are not used by Fedora anaconda. ERRATA may be used in Red Hat Enterprise Linux, but anaconda does not have an upstream and almost never fixes bugs in the current release - doing so would require a complete respin of all install media offered.

Other

• When bugs are reassigned from anaconda to another component, anaconda-maint-list@redhat.com should be removed from the CC list, for reasons similar to the ones given in the section on ASSIGNED.
• Checking for duplicates can be difficult. See Duplicate Searching for some tricks.
• These are not strict rules, but general best practice guidelines. When directed to do so by a developer, any of these guidelines may be broken.
• If you have questions about these guidelines, talk to Andy Lindeberg - alindebe@redhat.com, or alindebe on FreeNode.