QA/Bugzilla/FAQ
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Spende
Hier sind die Antworten auf häufig gestellte Fragen (FAQ) über Bugzilla.
Erweiterungsanfragen zu Bugzilla selbst
Senden Sie Erweiterungsanfragen für Bugzilla und andere relevante Infrastruktur als Redmine Ticket der Kategorie Bugzilla.
Zitate von anderen Kommentaren
Überflüssige und längere Zitate sollten vermieden werden. Es ist lästig, endlose Wiederholungen lesen zu müssen. Es ist immer hilfreich, die Bugzilla [reply] Funktion zu verwenden. Um einen Kommentar in einen Kontext zu setzen, können ein oder zwei relevante Zeilen zitiert werden, aber bitte keine Zitate über mehrere Zeilen.
Also: bitte NIEMALS das eMail-Programm für Kommentare nutzen. Kommentare zum Fehler werden in Bugzilla eingegeben, dort haben Sie viele Informationen, die im letzten Kommentar der eMail nicht sichtbar sind.
Zitate von anderen LibreOffice Fehlern in Bugzilla
Einen Bezug auf einen anderen Fehler können Sie über die Fehlernummer (z. Bsp. Fehler 12345) herstellen. Kein "#", keine Schnörksel zur Fehlernummer. Generell kann die ganze Betreffzeile des Fehlers zum Zitieren verwendet werden.
Interpretationsmöglichkeiten der Whiteboard Target Informationen
target:3.7.0 in Whiteboard means that a fix has been "pushed" to the code for the master. The first public Version where it will be available will be 4.0.0.x. If you wonder why a fix has not been integrated into the code for particular version, be patient! Before a fix can be integrated into current code branches the fix has to be reviewed by other developers to avoid regression bugs. That takes some time. As long as the bug has not changed status to FIXED you can hope for fix integration into the current branches' code.
Klone von Fehlerbeschreibungen
Sometimes a reporter accidentally creates several clones of the intended bug report. Please do NOT mark those useless clones as DUPLICATES. Many Duplicates should be an indicator that a particular problem affects many users. Instead, close each unneeded report as as RESOLVED - INVALID with the comment "Clone of Bug xxxxx".
How to use attached sample documents for multiple bug reports
It is neither necessary nor useful to attach the same document in multiple bug reports again and again. Instead, create a link with the text "attachment 12345 from Bug 6789" in the comment text or report text of the new bug report. This creates a link to download the attachment easily, and you contribute information about what other bug report may contain interesting information concerning the document.
To find the attachment number, mouseover the link in the original report, as the screenshot shows. Or you can copy / paste that info from the Bugzilla Attachment Details Info page. It's important to know for what bug report the attachment has been submitted, since the Comments often contain important additional information.
This way everybody knows that the sample document in the new bug report is identical to the document in the earlier bug report, so it is much more easy to compare results.
How to add bug reports to MAB bug tracking
See the special page about Most Annoying Bugs.
How to Validate a Bug Fix
If you tried to reproduce a bug with a version which should have included the fix (see target information in Whiteboard) and you can confirm that the bug no longer exists, you can modify the bug report Status to VERIFIED. This indicates that the fix has been confirmed. If you still can reproduce the bug please keep in mind How to reopen a bug.
How to attach Backtraces
If you want to provide extra information for the developers like Backtraces and similar material, you will have to decide whether you will contribute information
- As text in a Comment
- Advantages:
- queries can be done for Backtrace contents
- Advantages:
- Disadvantages:
- strings in Backtrace might bring up unwanted hits in queries
- bad readability of the Bugzilla bug report because of endless Backtrace comment texts
- Disadvantages:
- As an Attachment - text document
- Advantages:
- readability of the Bugzilla Bug is not reduced
- Advantages:
- If there are new findings you can mark an attachment as obsolete
- Disadvantages:
- No queries concerning Backtrace contents are possible
- No unwanted hits in queries by strings in Backtrace matching with "normal" query strings
It's your decision what way you prefer.
The most simple and reliable way is to write Bug 47712 (for example) instead of <https://bugs.documentfoundation.org/show_bug.cgi?id=47712>. Bugzilla will add a link to the text when it appears in a report or comment. For attachments, you should write attachment 61814 instead of <https://bugs.documentfoundation.org/attachment.cgi?id=61814>.
What's libreoffice.org/bugzilla?
No, not a new bugzilla of our own, but the Bugzilla environment for our Bugzilla. Mostly if you find such a link (in an URL field) concerning reported Bugs you should replace it by a bugs.documentfoundation.org/ URL to avoid login problems and similar (please compare Bug Links in #How to mention Attachments or other LibO related bug reports.
How do I find information I need?
Here you can find several useful queries:
- Bugs still waiting for a developer
- Bugs waiting for QA Review
For users of 64-bit operating systems
It is possible to run 32-bit applications on 64-bit operating systems. This might make the Platform chooser in Bugzilla a bit confusing. In general, please enter what your version of LibreOffice was built for. This information is sadly not visible in the application, however:
- Windows users: both 32-bit and 64-bit versions are available. In the case of a 32-bit version, use "x86 (IA32)". Please mention your operating system under Description.
- Linux users: in most cases you are using a 64-bit version of LibreOffice, if your system is 64-bit. Your package manager might give further hints. Use "x86-64 (AMD64)" with the 64-bit version.
- MacOS users: MacOS does only support 64-bit.
How to reopen a bug report
See details here.
How to Mark a Bug Report as a Duplicate
If you find out that a bug report (for example tdf#40691) is a DUPLICATE of an existing one (tdf#37195), decide which of the two to retain. Usually you retain the older report, but sometimes the newer report has additional valuable information, or has a more advanced status (Assigned).
When you have decided which report to retain, mark the other report as Duplicate, (tdf#40691) inserting the number of the report you are retaining (37195) into the pane that opens when you click Mark as Duplicate. It is not necessary to transfer reporter and CC list to the remaining report tdf#37195, because Bugzilla will send information on all changes in the remaining report to reporters and CC of reports closed as duplicates.
How to close a bug report if the bug can't be reproduced any longer
If a bug report has been confirmed, but the problem vanished with a later LibreOffice version, do not use Resolved Fixed to close the report. That is reserved for bugs with an identified fix. The appropriate Status for a bug where the problem simply vanished is Resolved - WORKSFORME.
There are several reasons why you might be unable to reproduce the issue:
- Step by step instructions to reproduce the bug are too unclear so that you did a test different from the reporter's test.
- The problem is real, but is related to a particular, so far unknown, condition. Your test did not include that condition.
- The issue was actually fixed, but we're not sure what fixed it.
Therefore, if you haven't reproduced the problem before, describe exactly how you did your test, and ask other contributors who have previously reproduced the issue if they still see it in a current version.
Only close a bug as "WORKSFORME" if you can reproduce it in an older version, but can't anymore in a current version.
How to assign a bug report (QA Team only)
- User Account of Friendly Expert (or known developer for the issue) will be inserted in CC by an experienced user. Status remains (or becomes) New
- Developer accepts the bug report by
- adding himself to Assigned to and
- changing Status to ASSIGNED
or does not accept the bug assignment.
Bug still visible although bug status FIXED?
The fix may not have been integrated into the next release. Please see Target information in Whiteboard or GIT link.
RC Version vanished?
You filed a bug report, but now you can't find it with "Search by Version" (for example using a link you bookmarked)? The reason might be that you discovered the bug in the last Release Candidate before the release. If the LibreOffice Release version is bit by bit identical to the last RC, the RC version from Version Picker will be changed to Release Version (for Example: 3.4.2 RC to 3.4.2 release) by the administrator.
Bugzilla Voting?
Bugzilla has a feature that lets project members vote for bug reports that they think should get attention sooner. LibreOffice does not use this feature, as the Engineering Steering Committee does not believe that simply voting brings enough new information.
That does not mean that there is a fundamental resistance to any sort of "user poll", however. If someone has a well-founded, convincing concept to propose, we can discuss the question again; and if feedback is positive we will find an infrastructure for the process.