From The Document Foundation Wiki
    < QA‎ | Bugzilla‎ | Fields‎ | Status

    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:


    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.


    • 'Blue 1' is set to the same color as 'Sky Blue 1' - tdf#86511
      • Whiteboard: target:4.5.0 target:

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


    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.


    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


    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".


    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.

    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 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.


    • 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 input to the whiteboard backportRequest:<active branch(es)>. 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.


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


    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


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


    • 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


    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.


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


    • 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


    • A handful of names for this status were proposed:
      • 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