QA/Bugzilla/Fields/Status/RESOLVED
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
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:<LO version X.y.z> 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' - tdf#86511
- 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 #INSUFFICIENTDATA 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.
Please don't use this value if the same person has reported the exact same issue twice, as this would skew our metrics. Instead, close the duplicate(s) as "INVALID".
WORKSFORME
In shorthand, WORKSFORME is written "WFM".
Someone in QA has tested this bug using the provided steps and/or test documents, could reproduce it in an older version, but can't anymore in a current version.
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.
The decision to close a bug as WFM without feedback from the original reporter or confirmers is done on a case by case basis. Normally it is good to give others some time to test. The age of the report and its last confirmation should be taken into consideration.
The reason a bug is WFM in the same reproduction environment could be that the user profile was corrupt. Make sure to ask the bug reporter to test LibreOffice in Safe Mode and see if resetting the user profile (after backup) resolves their issue.
Fixed in a newer version
If a bug is gone in master but not in one of the currently maintained release branches (see our release plan), the bug is considered resolved, and so we'll mark the bug as WFM.
Examples:
- tdf#74300 - Base:Database "Position and Size" box does not paint - it displays what's beneath it instead
- tdf#79289 - 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 add to the whiteboard backportRequest:<active branch>. 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:
|
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 commenting on the report or gerrit), the backportRequest:X.y tag may be removed and replaced with backportDenied:X.y.
If the fixing commit has been identified, the report can be resolved as "FIXED", or "DUPLICATE" if that commit closes another report that was describing essentially the same issue.
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 tdf#85643
- Round-off errors that occur due to floating-point arithmetic on integer values - tdf#86174
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 tdf#81854
- Excel has a longstanding date bug that they can't fix due to backwards-compatibility issues tdf#86996
- There's a limitation with software outside our control tdf#85652 redmine#845
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