Difference between revisions of "BUGZILLA/FAQ"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Meaning of bracketed branch names in the summary: minor rephrasing)
(BIDI)
 
(19 intermediate revisions by 4 users not shown)
Line 9: Line 9:
 
=== How to use attached sample documents for multiple Bug Reports ===
 
=== How to use attached sample documents for multiple Bug Reports ===
 
If an appropriate document to reproduce the problem or to show the problem (screenshot) already does exist in Bugzilla, please [https://wiki.documentfoundation.org/QA/Bugzilla/FAQ#How_to_use_attached_sample_documents_for_multiple_Bug_Reports cite the document instead of attaching it again]. That saves time, because other users, who might know the existing attachment, do not need to check whether the new attachment contains new information (and only looks similar) or simply is a clone.
 
If an appropriate document to reproduce the problem or to show the problem (screenshot) already does exist in Bugzilla, please [https://wiki.documentfoundation.org/QA/Bugzilla/FAQ#How_to_use_attached_sample_documents_for_multiple_Bug_Reports cite the document instead of attaching it again]. That saves time, because other users, who might know the existing attachment, do not need to check whether the new attachment contains new information (and only looks similar) or simply is a clone.
 +
[[File:ReplaceAllByI.png|320px|thumb|right|replace all characters by "i"]]
 +
=== How to attach sample documents with confidential contents ===
 +
Often it is very hard or even impossible to remove all confidential text contents from a (Writer) document. For many cases there is a simple alternative: replace all characters by an "i":
 +
# {{key|Ctrl|f}} for 'Search & Replace'
 +
# Find string: "."
 +
# Replace string: "i"
 +
# Regular Expressions: on
 +
# [Replace All]
 +
It's recommended to add some meaningful texts at relevant places ("Here Indent is Wrong").
  
 
== Bug Summary ==
 
== Bug Summary ==
Line 14: Line 23:
  
 
=== Meaning of bracketed branch names in the summary ===
 
=== Meaning of bracketed branch names in the summary ===
Development often happens in [https://en.wikipedia.org/wiki/Branching_%28revision_control%29 code branches]. Development branches are usually very interesting because they contain important new features or major cleanups. But code in branches is mostly not yet ready for general consumptions and needs to be extensively tested before it can be integrated. When such branches are tested the bugs found are very valuable for everyone working on that branch but of little value for the general public. So if a problem occurs only on a development branch then please use the bracketed branch name in the bug summary to make things as clear as possible. Examples of such tags used were e.g. [sidebar], [ia2], [aw080], etc.
+
Development often happens in [https://en.wikipedia.org/wiki/Branching_%28revision_control%29 code branches]. Development branches are usually very interesting because they contain important new features or major cleanups. But code in branches is mostly not yet ready for general consumptions and needs to be extensively tested before it can be integrated. When such branches are tested the bugs found are very valuable for everyone working on that branch but of little value for the general public. So if a problem occurs only on a development branch then please use the bracketed branch name in the bug summary to make things as clear as possible. Examples of such tags used were e.g. [sidebar], [ia2], [aw080], etc. If the integration of a code branch into the mainline has introduced problems then adding the branch tag also makes very much sense.
  
=== Meaning of bracketed pseudo key words in the summary ===
+
=== Meaning of bracketed pseudo keywords in the summary ===
In order to make bug summaries as concise as possible experienced bug reporters used pseudo tags directly in the summary. They are often obsolete nowadays because some bugzilla fields are better suited for marking the kind of bug.
+
In order to make bug summaries as concise as possible experienced bug reporters used pseudo tags directly in the summary. They are often obsolete nowadays because some Bugzilla fields are better suited for marking the kind of bug.
  
 
Examples for pseudo tags that were used are:
 
Examples for pseudo tags that were used are:
 
* '''[Regression]''' Deprecated tag for AOO regression issues. The "regression" keyword should be added to the '''Keywords''' field instead.
 
* '''[Regression]''' Deprecated tag for AOO regression issues. The "regression" keyword should be added to the '''Keywords''' field instead.
 
* '''[RFE]''' deprecated for ''Request For Enhancement''. Set the '''Issue Type''' selector to ENHANCEMENT instead.
 
* '''[RFE]''' deprecated for ''Request For Enhancement''. Set the '''Issue Type''' selector to ENHANCEMENT instead.
* '''[WW8]''' Bug related to WW8 import filter (for Word.Document.8)  
+
* '''[WW8]''' Bug related to WW8 import filter (WW8 denotes the Microsoft Word binary file format - [https://msdn.microsoft.com/en-us/library/cc313153%28v=office.12%29.aspx specification found here])
  
 
== Bug STATUS ==
 
== Bug STATUS ==
Line 29: Line 38:
 
==== Should I report new bugs with initial Status CONFIRMED? ====
 
==== Should I report new bugs with initial Status CONFIRMED? ====
 
The CONFIRMED status means that the bug report is clear enough and has sufficient details for another person to replicate the bug on another system.
 
The CONFIRMED status means that the bug report is clear enough and has sufficient details for another person to replicate the bug on another system.
So the answer is generally '''no'''! Even if you are pretty sure that you found a real bug and added lots of relevant information, generally following the [http://en.wikipedia.org/wiki/Two-man_rule#Other_uses Two Men Rule] results in better reports, what leads to faster bug fixing costing less developer resources. But of course, if you are an experienced bug tester (relevant contribution in more than 100 bugs or similar qualification), you might find good reasons to ignore the Two Men Rule and to select initial Status CONFIRMED
+
So the answer is generally '''no'''! Even if you are pretty sure that you found a real bug and added lots of relevant information, generally following the [https://en.wikipedia.org/wiki/Two-man_rule#Other_uses Two Men Rule] results in better reports, what leads to faster bug fixing costing less developer resources. But of course, if you are an experienced bug tester (relevant contribution in more than 100 bugs or similar qualification), you might find good reasons to ignore the Two Men Rule and to select initial Status CONFIRMED
  
 
==== When should I change Status from UNCONFIRMED to CONFIRMED? ====  
 
==== When should I change Status from UNCONFIRMED to CONFIRMED? ====  
Please do not change to CONFIRMED only because you were able to reproduce reporter's observations. The right moment for CONFIRMED is when [http://www.openoffice.org/qa/issue_handling/basic_rules.html#complete all relevant information]  has been gained.  
+
Please do not change to CONFIRMED only because you were able to reproduce reporter's observations. The right moment for CONFIRMED is when [https://www.openoffice.org/qa/issue_handling/basic_rules.html#complete all relevant information]  has been gained.  
 
# Report is a [[QA/HowToFileIssue#Principles|Good Bug Report]]
 
# Report is a [[QA/HowToFileIssue#Principles|Good Bug Report]]
 
## Check for duplicates has been proceeded?
 
## Check for duplicates has been proceeded?
 
## Summary is clear and specific enough to distinguish the reported bug from other similar ones
 
## Summary is clear and specific enough to distinguish the reported bug from other similar ones
## Sample Document available? Even if it seems to be simple for QA staff to create own sample documents, it saves a lot of time if a sample is attached. and Additionally the sample document can contribute additional relevant information (Localization, Language, Formatting caused by repoerter's very special ''New Document Templates'', ...
+
## Sample Document available? Even if it seems to be simple for QA staff to create own sample documents, it saves a lot of time if a sample is attached. Additionally the sample document can contribute additional relevant information (Localization, Language, Formatting caused by reporter's very special ''New Document Templates'', ...
 
# Other selectors with correct contents?
 
# Other selectors with correct contents?
 
## Relation to Operating System checked?
 
## Relation to Operating System checked?
## Most early OO Version with what the bug has been observed selected (if possible, do your own tests with older versions)
+
## Most early AOO Version with what the bug has been observed selected (if possible, do your own tests with older versions)
 
## Appropriate Importance?
 
## Appropriate Importance?
 
## Keywords appropriate?
 
## Keywords appropriate?
 
# All or at least most relevant aspects of the bug are listed in the report
 
# All or at least most relevant aspects of the bug are listed in the report
  
If these conditions are fulfilled you should select CONFIRMED. But of course, it's a matter of consideration, an important CRASH-Regression should be taken by developers as soon as possible, here it would be inappropriate to leave Status UNCONFIRMED because some minor questions are without answer.
+
If these conditions are fulfilled, you should select CONFIRMED. But of course, it's a matter of consideration, an important CRASH-Regression should be taken by developers as soon as possible, here it would be inappropriate to leave Status UNCONFIRMED because some minor questions are without answer.
  
 
== Mixed ==
 
== Mixed ==
 
=== From where can I download latest test versions? ===
 
=== From where can I download latest test versions? ===
You can test latest bug fixes with unstable test builds from [http://ci.apache.org/projects/openoffice/index.html here].
+
You can test latest bug fixes with unstable test builds from [https://nightlies.apache.org/openoffice/index.html here].
 +
 
 +
=== How To Cite Bugzilla Comments ===
 +
When you have clicked "reply" the comment field will contain a citation of the complete Comment to what you want to reply. That is an offer, please delete anything what is not required for understanding your reply. Mostly the heading line "(In reply to xyz from comment #6)" is enough. If you cite a part of an other comment please reply '''below''' citation.
  
 
=== How To Crash AOO ===
 
=== How To Crash AOO ===
Line 61: Line 73:
 
If you want to add a Bug report (like [https://issues.apache.org/ooo/show_bug.cgi?id=122762 Bug 122762]) to a TASK Tracking Bug (like [https://issues.apache.org/ooo/show_bug.cgi?id=122364 Tracking  Bug 122364]), the best way is  
 
If you want to add a Bug report (like [https://issues.apache.org/ooo/show_bug.cgi?id=122762 Bug 122762]) to a TASK Tracking Bug (like [https://issues.apache.org/ooo/show_bug.cgi?id=122364 Tracking  Bug 122364]), the best way is  
 
# Add Bug number to ''Depends on'' field in TASK Tracking Bug
 
# Add Bug number to ''Depends on'' field in TASK Tracking Bug
# [https://issues.apache.org/ooo/show_bug.cgi?id=122364#c3 Cite] complete Heading line of "Depends-On-Bug" in a ''Comment'' in the TASK Tracking Bug.  
+
# Cite complete ''Summary'' line (including "Issue 123456 - " of "Depends-On-Bug" in a ''Comment'' in the TASK Tracking Bug. So all interested users listed in CC of TASK Tracking Bug will get a summary of the new bug with mail from bugzilla@apache.org and can see immediately what the reported problem is - no need for a detour to the tracking Bug (and several clicks).
:: So all interested users listed in CC of TASK Tracking Bug will get a summary of the new bug with mail from bugzilla@apache.org and can see immediately what the reported problem is - no need for a detour to the tracking Bug (and several clicks).
+
# If it's not obvious, add reason(s) why you think that that particular report should be listed in the tracking bug.
  
 
=== How to attach screenshots with additional graphic contents ===
 
=== How to attach screenshots with additional graphic contents ===
If you want to add some graphic contents to a screenshot to make it more comprehensible, you should copy the clipboard contents with the screenshot to a new DRAW document and add emphasis, text ideas, callouts, pointer arrows or whatever in the Draw document. If you save it with 'File -> Properties -> Security - open File Readonly' before aou attach it in the Bug, the document is protected against unintended edits, but can be edited if appropriate by other users.
+
If you want to add some graphic contents to a screenshot to make it more comprehensible, you should copy the clipboard contents with the screenshot to a new DRAW document and add emphasis, text ideas, callouts, pointer arrows or whatever in the Draw document. If you save it with {{menu|File|Properties|Security|open File Read only}} before you attach it to the Bug, the document is protected against unintended edits, but can be edited if appropriate by other users.
  
 
=== What is the best file type for screenshots? ===
 
=== What is the best file type for screenshots? ===
 
Graphic formats with lossless compression like "PNG" are much more suitable than JPG, because no compression artifacts compound recognition of details.
 
Graphic formats with lossless compression like "PNG" are much more suitable than JPG, because no compression artifacts compound recognition of details.
 +
 +
== How to improve Bugzilla Help texts ==
 +
Temporary
 +
 +
Here we collect suggestions for improved texts.
 +
=== General ===
 +
All Help texts should show whether keyword, Component or whatever still are in use or obsolete /deprecated. If it is possible without causing mass mails we should think about a code indicating  obsolete / deprecated items in the selectors, may be by a trailing dot or similar.
 +
 +
=== Keywords ===
 +
==== crash ====
 +
'''Suggestion''': Drop keyword
 +
* '''Pro''':
 +
** We have [https://issues.apache.org/ooo/buglist.cgi?keywords=crash%2C%20&keywords_type=allwords&limit=0&list_id=131629&order=bug_status%2Cbug_id%20DESC&query_format=advanced 837 Bug reports] with that keyword, [https://issues.apache.org/ooo/buglist.cgi?f1=short_desc&keywords=crash%2C%20&keywords_type=allwords&list_id=131630&o1=notsubstring&query_format=advanced&v1=crash 209 of them] without "crash" string in summary , [https://issues.apache.org/ooo/buglist.cgi?f1=short_desc&keywords=crash%2C%20&keywords_type=allwords&list_id=131632&o1=notsubstring&query_format=advanced&short_desc=freeze%20hang&short_desc_type=anywordssubstr&v1=crash 66 of these] with "hang" or "freeze" in summary, more than [https://issues.apache.org/ooo/buglist.cgi?f1=keywords&limit=0&list_id=131635&o1=notsubstring&order=bug_status%2Cbug_id%20DESC&query_format=advanced&resolution=---&short_desc=crash%20hang%20freeze%20froze&short_desc_type=anywordssubstr&v1=crash 1800 Bug reports] concerning crash, hang, freeze without "crash" key word. That makes reliable queries rather expensive. If it's a hang an additional "(Crash)" in summary instead of extra key word might ease that very much.
 +
* '''Contra''':
 +
 +
==== accessibility ====
 +
'''Old''':
 +
: Issues referring to the accessibility of the product should have this keyword.
 +
'''New''':
 +
: Issues referring to the [https://www.openoffice.org/ui/accessibility/whitepaper.html accessibility] (for users with handicap) of the product should have this keyword.
 +
 +
==== BIDI ====
 +
'''Old''':
 +
: This keyword marks issues related to bi-directional support.
 +
'''New''':
 +
: For issues related to bi-directional support.
 +
:: Bi-Directional communications allows the computers to be notified of the status of the printer when a person starts printing (Such as tray status, ink/toner levels, paper jams, etc.) While uni-directional only allows computers to send commands to the printer.
 +
  
  
 
[[Category:Quality Assurance]]
 
[[Category:Quality Assurance]]

Latest revision as of 11:36, 9 August 2022

This page lists several FAQ how to use the AOO-BUGZILLA

Attachments and Sample Documents

What are good Sample Documents?

Providing a sample document usually helps to reproduce a problem and to test the fix. Sample documents should be minimal, e.g. if you notice a bug in the upper left corner on page 345 of a 1000 page document then it is advisable to check whether the bug can still be replicated if the other pages are removed. Removing as much content that does not impact the reproducibility of the bug helps everyone who wants to work on that bug report.

How to use attached sample documents for multiple Bug Reports

If an appropriate document to reproduce the problem or to show the problem (screenshot) already does exist in Bugzilla, please cite the document instead of attaching it again. That saves time, because other users, who might know the existing attachment, do not need to check whether the new attachment contains new information (and only looks similar) or simply is a clone.

replace all characters by "i"

How to attach sample documents with confidential contents

Often it is very hard or even impossible to remove all confidential text contents from a (Writer) document. For many cases there is a simple alternative: replace all characters by an "i":

  1.  Ctrl  +  f  for 'Search & Replace'
  2. Find string: "."
  3. Replace string: "i"
  4. Regular Expressions: on
  5. [Replace All]

It's recommended to add some meaningful texts at relevant places ("Here Indent is Wrong").

Bug Summary

Be as concise as possible in the bug Summary. The more specific a bug summary is the more useful it is for others such as when you report a new bug you will notice that bugzilla tries to find similar bugs that might be of interest. So instead of having a summary "Bug in Writer!!!" please be more specific and write e.g. "Writer prints green text underlines as blue on a Windows GDI printer".

Meaning of bracketed branch names in the summary

Development often happens in code branches. Development branches are usually very interesting because they contain important new features or major cleanups. But code in branches is mostly not yet ready for general consumptions and needs to be extensively tested before it can be integrated. When such branches are tested the bugs found are very valuable for everyone working on that branch but of little value for the general public. So if a problem occurs only on a development branch then please use the bracketed branch name in the bug summary to make things as clear as possible. Examples of such tags used were e.g. [sidebar], [ia2], [aw080], etc. If the integration of a code branch into the mainline has introduced problems then adding the branch tag also makes very much sense.

Meaning of bracketed pseudo keywords in the summary

In order to make bug summaries as concise as possible experienced bug reporters used pseudo tags directly in the summary. They are often obsolete nowadays because some Bugzilla fields are better suited for marking the kind of bug.

Examples for pseudo tags that were used are:

  • [Regression] Deprecated tag for AOO regression issues. The "regression" keyword should be added to the Keywords field instead.
  • [RFE] deprecated for Request For Enhancement. Set the Issue Type selector to ENHANCEMENT instead.
  • [WW8] Bug related to WW8 import filter (WW8 denotes the Microsoft Word binary file format - specification found here)

Bug STATUS

CONFIRMED

Should I report new bugs with initial Status CONFIRMED?

The CONFIRMED status means that the bug report is clear enough and has sufficient details for another person to replicate the bug on another system. So the answer is generally no! Even if you are pretty sure that you found a real bug and added lots of relevant information, generally following the Two Men Rule results in better reports, what leads to faster bug fixing costing less developer resources. But of course, if you are an experienced bug tester (relevant contribution in more than 100 bugs or similar qualification), you might find good reasons to ignore the Two Men Rule and to select initial Status CONFIRMED

When should I change Status from UNCONFIRMED to CONFIRMED?

Please do not change to CONFIRMED only because you were able to reproduce reporter's observations. The right moment for CONFIRMED is when all relevant information has been gained.

  1. Report is a Good Bug Report
    1. Check for duplicates has been proceeded?
    2. Summary is clear and specific enough to distinguish the reported bug from other similar ones
    3. Sample Document available? Even if it seems to be simple for QA staff to create own sample documents, it saves a lot of time if a sample is attached. Additionally the sample document can contribute additional relevant information (Localization, Language, Formatting caused by reporter's very special New Document Templates, ...
  2. Other selectors with correct contents?
    1. Relation to Operating System checked?
    2. Most early AOO Version with what the bug has been observed selected (if possible, do your own tests with older versions)
    3. Appropriate Importance?
    4. Keywords appropriate?
  3. All or at least most relevant aspects of the bug are listed in the report

If these conditions are fulfilled, you should select CONFIRMED. But of course, it's a matter of consideration, an important CRASH-Regression should be taken by developers as soon as possible, here it would be inappropriate to leave Status UNCONFIRMED because some minor questions are without answer.

Mixed

From where can I download latest test versions?

You can test latest bug fixes with unstable test builds from here.

How To Cite Bugzilla Comments

When you have clicked "reply" the comment field will contain a citation of the complete Comment to what you want to reply. That is an offer, please delete anything what is not required for understanding your reply. Mostly the heading line "(In reply to xyz from comment #6)" is enough. If you cite a part of an other comment please reply below citation.

How To Crash AOO

For some investigations it is necessary to provoke a crash. You can find possibilities how to crash AOO with this Bugzilla query, what shows current crash-bugs.

What is the appropriate Version in Bugzilla Version selector?

The most early AOO or OOo version with what the problem has been observed. For Regression bugs Version information will help developers to find the code change what causes the problem.

In August 2013 the syntax for AOO versions in the selector has been changed, the AOO prefix has been dropped for most AOO versions. For historical reasons (?)some Versions with AOO prefix remained. If you work on such a bug report please always think about switching to a "modern" version.

How to connect a Bug report to a Tracking Bug

If you want to add a Bug report (like Bug 122762) to a TASK Tracking Bug (like Tracking Bug 122364), the best way is

  1. Add Bug number to Depends on field in TASK Tracking Bug
  2. Cite complete Summary line (including "Issue 123456 - " of "Depends-On-Bug" in a Comment in the TASK Tracking Bug. So all interested users listed in CC of TASK Tracking Bug will get a summary of the new bug with mail from bugzilla@apache.org and can see immediately what the reported problem is - no need for a detour to the tracking Bug (and several clicks).
  3. If it's not obvious, add reason(s) why you think that that particular report should be listed in the tracking bug.

How to attach screenshots with additional graphic contents

If you want to add some graphic contents to a screenshot to make it more comprehensible, you should copy the clipboard contents with the screenshot to a new DRAW document and add emphasis, text ideas, callouts, pointer arrows or whatever in the Draw document. If you save it with File → Properties → Security → open File Read only before you attach it to the Bug, the document is protected against unintended edits, but can be edited if appropriate by other users.

What is the best file type for screenshots?

Graphic formats with lossless compression like "PNG" are much more suitable than JPG, because no compression artifacts compound recognition of details.

How to improve Bugzilla Help texts

Temporary

Here we collect suggestions for improved texts.

General

All Help texts should show whether keyword, Component or whatever still are in use or obsolete /deprecated. If it is possible without causing mass mails we should think about a code indicating obsolete / deprecated items in the selectors, may be by a trailing dot or similar.

Keywords

crash

Suggestion: Drop keyword

  • Pro:
    • We have 837 Bug reports with that keyword, 209 of them without "crash" string in summary , 66 of these with "hang" or "freeze" in summary, more than 1800 Bug reports concerning crash, hang, freeze without "crash" key word. That makes reliable queries rather expensive. If it's a hang an additional "(Crash)" in summary instead of extra key word might ease that very much.
  • Contra:

accessibility

Old:

Issues referring to the accessibility of the product should have this keyword.

New:

Issues referring to the accessibility (for users with handicap) of the product should have this keyword.

BIDI

Old:

This keyword marks issues related to bi-directional support.

New:

For issues related to bi-directional support.
Bi-Directional communications allows the computers to be notified of the status of the printer when a person starts printing (Such as tray status, ink/toner levels, paper jams, etc.) While uni-directional only allows computers to send commands to the printer.
Personal tools