QA/Bugzilla/Fields/Status/RESOLVED/en

Purpose of this Page
This page is about the RESOLVED state of the Status Field in Bugzilla. It is dedicated to explaining and clarifying the purpose of the multiple RESOLVED states as well as describing the steps which QA can/will take in addressing RESOLVED bugs.

The Meaning of RESOLVED
There are a bunch of sub-states for RESOLVED:
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 

FIXED
This bug has been fixed by a particular commit. There should be one or more target: tags in the Whiteboard, each of which indicates a version/branch of LibreOffice in which this commit will be included.

Examples:
 * 'Blue 1' is set to the same color as 'Sky Blue 1' -
 * Whiteboard: target:4.5.0 target:4.4.0.0.beta2

If you do not know which commit fixed a bug -- use RESOLVED WORKSFORME instead.

INVALID
Something about this bug report is invalid or does not compute. For example if someone files a report like this, we'd resolve it as INVALID:

I am a walrus I am a walrus and I think everyone should know. The repro steps are eating fish.

Previously, we'd use the RESOLVED INVALID status as a catch-all for various families of bugs, including bugs that had sat in NEEDINFO state for over half a year, and that we wanted to set aside. Now we have the status which is a better fit for those categories of bugs.

WONTFIX
This may be a bug, but we aren't planning to fix it for some reason (which is usually detailed in a comment when the bug is resolved as WONTFIX). Examples include:
 * A bug that doesn't affect any actual users

DUPLICATE
This bug is a duplicate of another bug already in the system

WORKSFORME
In shorthand, WORKSFORME is written "WFM".

Someone in QA has tested this bug and is unable to reproduce it using the provided steps and/or test documents.

Same Reproduction Environment
If you have the same environment as the bug reporter (e.g. same OS, same version of LibreOffice), we feel a lot more confident about marking a bug as WFM. If you don't have the same environment (e.g. same LO version, but they're on Windows and you're on macOS), see if someone in the QA/IRC channel has the same environment and can double-check your work.

Fixed in a newer version
If a bug is fixed in master but not in Fresh, or in Fresh, but not in Still, the bug is considered fixed, and so we'll mark the bug as WFM.

Examples:
 * - Base:Database "Position and Size" box does not paint - it displays what's beneath it instead
 * - FILEOPEN: DOCX shapes turn to frames and fill background not retained

If we know which commit fixed the problem, it's fine to ask the author (developer) if it's possible to backport the fix. If we don't know which commit fixed the bug, we need to figure that out. We can add the keyword bibisectRequest and input to the whiteboard backportRequest:. This will indicate that we need to do a "reverse" bibisect (to figure out when the bug was fixed, instead of when the bug was introduced :-)

Example whiteboard: backportRequest:4.2 backportRequest:4.3

''NOTE: Before you ping a developer asking for help, try to do the Bibisect work yourself to track down which commit fixed a bug. This helps the devs to get the most work done in each day!''

Once a bug is fixed on all active LibreOffice branches (either by backporting or by branches reaching EOL), or if a developer denies the backport request (by making a comment on the bug), the backportRequest:X.y tag may be removed and replaced with backportDenied:X.y.

MOVED
Used, when Bugzilla is not the proper place for the report.

NOTABUG
The "problem" described by the bug reporter is part of the expected behavior of LibreOffice. Examples:
 * A function works as expected
 * Round-off errors that occur due to floating-point arithmetic on integer values -

NOTOURBUG
There is a problem here, but it's not a problem in LibreOffice.

Examples:
 * LibreOffice reads/write the file format correctly, but some other software does not
 * Excel has a longstanding date bug that they can't fix due to backwards-compatibility issues
 * There's a limitation with software outside our control

INSUFFICIENTDATA
As requested in an ESC call, this Status was added to encompass bugs that have been abandoned or don't have enough data for us to proceed with triage and bugfixing.

Examples:
 * User isn't willing to share a private document with anyone, and we can't reproduce
 * Bug sits in NEEDINFO status for 6+ months

Reasoning:
 * We currently mark abandoned bugs as RESOLVED WORKSFORME, or RESOLVED INVALID, but an additional Status value could help us be more precise in indicating why a bug has been set aside.
 * An additional Status would allow us to be more diplomatic with tough users, and avoid the potential negatives of "INVALID" or "WORKS FOR ME" on such bugs

Naming:
 * A handful of names for this status were proposed:
 * ABANDONED
 * INSUFFICIENT_DATA (Red Hat bugzilla)
 * EXPIRED (Launchpad)
 * The underscore between the two words "INSUFFICIENT_DATA" was removed to match the style of the existing RESOLUTION statuses in Bugzilla