TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

This page is the complete page for the Whiteboard (aka status_whiteboard) field in Bugzilla.

NOTE: Many of the Whiteboard tags have been migrated to the Keywords field.

Getting Started

Note: This page is currently in progress

The Whiteboard text box in bugzilla is where QA, Developers, and users can put specific terms to help organize our bug tracker. Unlike the Keywords field, there are no restrictions set by the bug tracker on what can go in the Whiteboard box. This being said we have some general guidelines:

use whiteboard status sparingly, many things can be accomplished by appropriately using version, OS, keywords, and comments
Whiteboard status' not listed below should be “vetted” (discussed) on the QA list before adding a new one
- If a new whiteboard status is desired, please email the QA list and explain what purpose it would serve.

Other Comments:

If the whiteboard status is a single word it is completely in lower case
If the whiteboard status is multiple words then the status is wimpyCaps (one run on word where each word after the first is capitalized)
Do NOT use commas – separate whiteboard status' with a space only
Whiteboard is meant to organize the bug tracker – use it wisely :)

Complete List of Accepted Whiteboard Tags

ODF related (should be keywords really)

odf

Description: a very general keyword for any kind of interoperability problem in consuming or producing ODF documents

Use: should be obvious

odf_validation

Description: is specifically for bugs about LO producing invalid or non-conforming ODF documents

Use: if an ODF validator complains about a document that LO produced (make sure you configure the ODF validator according to the version in Tools->Options->Load/Save->General->ODF format version)

Automatic Messages

target

Description: target refers to the version(s) where a commit which fixes the problem can be expected to be seen.

Use: Generally “target” is automatically entered when a developer commits a patch specifically to fix a bug reported on the bug tracker. Users, QA and Developer should generally not manually enter “target” into whiteboard, the only exception is when the automatic system did not tag the bug and a developer or QA member knows the exact commit which fixed the bug and what version of LibreOffice will see the patch. In these cases a QA member can mark a bug as “target:x.x.x.x” where x.x.x.x is the version(s) of LibreOffice where the commit was pushed to.

Example:

target:4.2.0.0

This means that a commit which fixes the problem was committed to the 4.2.0.0, and therefore if a user or QA member tests 4.2.0.0 they should not see the bug any longer.

BSA

Description: BSA refers to “Bug Submission Assistant” and when in the whiteboard means that the bug was submitted through our bug submission assistant. For more information about BSA click here.

Use: Always entered automatically, no need to ever manually put BSA into whiteboard.

Diagnostics

Bibisection

bibisectedNewer

Description: Used in cases where a bug has been confirmed to be a regression but the regression occurred after the last commit in the latest bibisect package.

Use: If a regression is confirmed on master or on a recent daily build then it's likely going to be too new to be bibisected. QA should still try to bibisect the bug just in case the bad commit is within the bibisect range.

commit:commit hash

Description: Used when the exact regression-causing commit has been found through bisection. Adding this to a report makes it easier to find duplicate regression reports and other bugs affected by the same commit.

Example:

commit:34d7602954d4483b3bc9db700e7df2c15348947a

Confirmation

confirmed:VERSION:OS

Description: Can be used to say that the bug was confirmed on a particular OS and using a particular version of LibreOffice.

Examples:

confirmed:4.1.3.2:ubuntu
confirmed:4.1.3.2:windows7
confirmed:4.2.0.1:macOS

Use: Not frequently used but can be used when wanting to add more information to a confirmed bug. Should always include “confirmed:” and then version and OS (see examples above).

backportRequest

Description: Used for bugs that are fixed in the master build, but aren't fixed in the Fresh or Still branches

Use: Should be used when a bug has been found to be fixed in the current master build but not in one of our active release branches. See the documentation for Status: RESOLVED.

Should be removed once a given bug has been fixed in all active release branches or replaced by backportDenied is it was rejected to be backported.

Example:

backportRequest:5.4

Reproducibility

noRepro:VERSION:OS

Description: Used when you are unable to reproduce the bug but are not comfortable closing the bug as LINK

WORKSFORME. Includes information about what version was used and the operating system of the tester.

Use: Generally used when the testing environment is different than the testing environment of the bug reporter so closing the bug as WORKSFORME status is less applicable. Used mostly by QA members and developers.

Examples: 
noRepro:4.1.3.2:ubuntu
noRepro:4.1.3.2:windows7
noRepro:4.2.0.1:macOS

needsSOFTWARE

Description: Used to highlight a particular piece of software that is required to triage the bug.

Use: Only used for unique software requirement. Not appropriate for “needsMSO” as Microsoft Office is relatively common but if the bug only affects Microsoft Office 2013 then using “needsMSO2013” is appropriate. Also not appropriate for “needsWindows” (setting version to “Windows(all)” is sufficient, but if a particular version of Windows is needed (such as XP) it is appropriate.

Examples:

needsAlfresco
needsWebDAV
needsWinXP
needsKDE

needsHARDWARE

Description: Used to highlight a particular piece of hardware that is required to triage the bug.

Use: Only used for unique hardware requirement.

Examples:

needsDuplexPrinter
needsBrotherPrinter
needsHPScanner

interoperability

Description: Used when the issue is an interoperability issue with Microsoft Office.

Use: To be used if the issue is with a Microsoft Office format (doc/docx, xls/xlsx, etc . . .). Use “filter:xxx” to specify a particular file format.

summary:comment#

Description: Tells future viewers of a bug which comment has the best description of the bug. Ideally, the comment should have clear reproducible steps to reproduce the bug.

Use: Can be used by anyone who sees a comment that is a better description of the bug than the original bug report.

Example:

summary:comment5

multipleBugs

Description: Use when a bug report has multiple bugs reported in a single bug report.

Use: Use if you decide to keep the bug report open for some reason (usually we close these as INVALID and ask the user to open individual reports for each issue) and are triaging a single issue out of all the issues reported. When confirming the issue make sure to address the issue that you were confirming in your comments and then tell the user to report new bugs for all other issues. Feel free to put “see also” in these bugs if they are dealing with the same document/attachment.

Release Notes

inReleaseNotes

Description: To track which new features have already been recorded in a major version's release notes.

Use : Similarly to the "target" value, the version number can be appended. QA members can mark a bug as “inReleaseNotes:x.x” where x.x is the major version of LibreOffice where the feature landed and for which the Release Notes wiki page has the feature description.

Example:

inReleaseNotes:24.2

Inactive

We have a number of whiteboard status' that have either been completely retired, consolidated or changed in one way or another. The list of these retired terms can be found here: QA/Bugzilla/Fields/Whiteboard/Inactive