QA/Test
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Automatic Messages
Target
Description: target refers to the version(s) where a commit which fixes the problem can be expected to be seen.
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.
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.
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.
PossibleRegression
Description: PossibleRegression is entered when a user has stated that the bug was not present in a previous release of LibreOffice and therefore it's a regression. The point of this status is so that QA can confirm that there is a regression and do the follow up steps needed for regressions (bibisect, etc . . .)
Use: PossibleRegression is entered automatically when a user enters a previous version in BSA where the bug was not present. PossibleRegression can be manually entered by a user when they are reporting directly to the bug tracker (ie. Not through BSA) if they believe that the bug is a regression – if they do this they should write in the bug description when the bug was not present.
No Longer In Use
Accessibility
Description: Replaced by a11y – see description there.
Use: No longer used. Replaced by a11y.
bibisected35older
Description: Was used to indicate that the bug was present before the bibisect35 package.
Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see LINK
here.
bibisected35
Description: Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect35 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see LINK
here.
Use: No longer used. Replaced by “bibisected”.
bibisected36
Description: Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect36 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see here.
Use: No longer used. Replaced by “bibisected”.
bibisected35newer
Description: Was used in the past to say that a regression was introduced after the bibisect35 package.
Use: No longer used.
bibisected36older
Description: Was used to indicate that the bug was present before the bibisect36 package.
Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see here.
bibisected40
Description: Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect40 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see here.
Use: No longer used. Replaced by “bibisected”.
bibisected40newer
Description: Was used in the past to say that a regression was introduced after the bibisect40 package.
Use: No longer used.
bibisected40older
Description: Was used to indicate that the bug was present before the bibisect40 package.
Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see here.
Currently In Use
a11y
Description: Used when the bug report is about an accessibility issue. Accessibility refers to bugs and enhancements which affect individuals with special needs. Applicable for both enhancement requests and bug reports.
Use: Manually entered by someone who knows about accessibility problems. These are specific to bugs which would affect the way that individuals with special needs interact with LibreOffice – generally not appropriate if it is just a request to make something easier for everyone.
bibisected
Description: Used for letting developers know that the bug has been bibisected. For more information on bibisect see LINK
here.
Use: Should be manually entered by the person attaching the bibisect details after bibisecting a bug.
EasyHack
Description: Used to denote a bug which has been determined to be a good start for a new developer on the project.
Use: Developers should be the only ones to use this whiteboard status. Developers add this status after they provide code pointers to fix the bug.
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.
Example(s): NoRepro:4.1.3.2:Ubuntu, NoRepro:4.1.3.2:Windows7, NoRepro:4.2.0.1:macOS
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.
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.
Example(s):
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).
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.
BibisectRequest
Description: Used to let us know that a bibisect is needed.
Use: All confirmed regressions after 3.5.0 should have a BibisectRequest whiteboard status unless the bug is specific to Windows (which should be confirmed prior to removing a BibisectRequest). Many bugs that affect Windows will also affect Linux and macOS so they can be bibisected successfully.
ConfirmedRegression
Description: Is used if a bug is confirmed to be a regression.
Use: If a bug is confirmed to be a regression then a user, QA, or developer can put ConfirmedRegression into the whiteboard. If this is done the individual should also put in the comments what version worked (and is confirmed to have worked) and what version does not.
DifficultyBeginner
Description: Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that not only is the bug an easy hack, it is “really easy” and can be done by individuals who have beginner skills in computer science.
Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.
DifficultyEasy
Description: Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that the bug is fairly easy but not quite easy enough for beginners.
Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.
DifficultyInteresting
Description: Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that while the bug is considered to be an easy hack by our experts, it could be quite challenging for a new developer on the project. Generally people who tackle these should be relatively comfortable with programming generally.
Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.