Bugzilla Help

Chapter 8. Bug Tracker

Find, report and fix bugs here http://bugs.contribs.org

You don't have to be a programmer to help or use the bug tracker. Bugs also include fixing and making suggestions on documentation, translations and the SME Server web sites.

General Instructions for using the bug Tracker

Searching for bugs

To help find bugs, some prepared searches have been added in page headers, with more BugzillaReports here

1. Simple search
At the top of the search page choose 'Find a specific bug'
Select a Status and a Product category and enter your search term

2. Advanced search
At the top of the search page choose 'Advanced search'

You can restrict searches by using a selection or multiple selections of a category
Use Control Click to select/deselect from selection sets, if none are selected all are.

typically you may restrict Product to use '7.x/Future/Documentation'
and enter a search term into either 'Summary' or 'A Comment'
In Comment, toggle between 'contains the string' 'contains all the words' ' contains any of the words' etc.

eg. Status = CLOSED, Resolution = WONTFIX, Summary = yum
will return about 7 bugs

eg. Status = CLOSED, Resolution = WONTFIX, A Comment = yum
will return about 17 bugs

• Modifying your search

- Click on the hyperlinked headers to sort your list

- Click 'Edit Search' near the page footer

• you can adjust your selection sets
• add a search tern in the summary or comments fields
• restrict the dates, eg between 365d and Now the last year, 60d and 7d from 2months ago but not the last week
• bugs you are working on or watching, add you email address to the left field in email and numbering and check cc:, commenter, etc

- If you have a favourite search,

• when the bug list is displaying, add a name in the Remember field, these will show in your footer
• add the search to the BugzillaReports page

Reporting Bugs

Please help us to make our software as reliable as possible. Your role in that is to report possible bugs only via the bug tracker, and to encourage others to do the same.

Everyone reporting bugs needs to read: How to report bugs effectively

Also see Reporting a New Bug and Bug Writing

If you have searched the Wiki, Forum and Bug Tracker and not found an answer or someone else's report that matches yours, you should register on the Bug Tracker and enter a new bug. The debugging process of any issue requires active participation on the part of the reporter, providing further information and clarification of the problem.

Anyone reporting problems, ask yourself these important questions, so that you know what to tell the developers in the bug report:

• What version am I using and are there any contribs installed or other customisations?
• What did I do?
• What did I expect to happen?
• What happened?
• What do the logs say?

Bug Verification

If you find a bug you can work on, please do so. As an example, the documentation section, only requires you to take the answer determined in the bug and copy the information onto the wiki. There are likely to be a lot of these as they were generated before the wiki was in place.

In this example of adding documentation,

• find a bug where you understand the problem resolved
• update the wiki, information will go in a manual, be added to the FAQ or a howto, or create a new howto
• return to the bug post brief details of the fix, and how to verify it, eg 'updated wiki re: passwords' and give the URL
• then change the Status to 'Resolved - Fixed'.
• let someone else verify, or verify someone else's work

Bug Status

Lifecycle of a Bug

Resolution status:

• UNCONFIRMED

New bugs submitted by ordinary users are created in this state. Note. Project Developers tend not to look at unconfirmed bugs as they only have so much time, so it's important regular users check each others bugs.

• NEW

Once bugs are confirmed, by anyone see note above, change the status to new,

---

• FIXED

Set to fixed after the problem has been solved for others, eg a new rpm is available, documentation has been added, etc.

For SmeServer category bugs changing to FIXED is reserved for devs.

Occasionally the dev will forget to set the FIXED status and as part of the verification process will be pushed to FIXED on the way to VERIFIED by the person verifying the package. It should never be set to FIXED or VERIFIED without having a released package that is in CVS.

Bugs in Documentation, Translation, Contribs, or Websites categories need community involvement, anyone can resolve these FIXED.

---

Alternatives to Fixed are :

• INVALID

If you see that a problem is not a bug. eg User error Mark INVALID if the report is of documented (i.e. expected and correct) behaviour, or was encountered in some explicitly unsupported circumstance

• WONTFIX

This bug is:
- Too hard to fix
- Too rare
- Not something we can fix
- Something we chose not to expend resources on fixing

This is a hard call, usually made by the dev team. It may be a serious issue for the reporter but we may simply say "Sorry, that's just not worth the effort involved"

• LATER

Leave the bug for later, eg in case another bug will fix a related issue.

• REMIND

Needs follow-up from the reporter or someone else to get any further. Please REOPEN bugs when the follow-up comes in.

• WORKSFORME

You've been able to show that the problem does not happen for you. You should do this on a known good test box without any contribs installed. Many of our reports are breakage due to contribs.

• DUPLICATE

For when the reporter didn't find the related bug.

---

• VERIFIED

Check the fix provided solves the issue.

• CLOSED

Bug Tracker Administrators Close bugs in SME Current or SME Future,
but the reporter or maintainer can close in other sections, eg Documentation, Websites, Contribs
There is no need to verify a non-fix. Invalid/wontfix bugs can move straight to closed.

Bugzilla flags

These will be obvious to the people they are intended to serve. If you feel comfortable setting them based on information contained in the bug or needs you have for the bug then set them. If not then leave them be.

• need_help_to_verify [-+?]

"I don't understand how to verify this bug - please help" - a request to the dev team or other verifiers to have another look at the bug. Please say what you don't understand and what you've looked at.

• package_maintained_upstream

The package is maintained in an upstream repository. We won't be patching it locally. We've deemed it to be not important enough for us to fork the package, and so we'll wait for the fix to propogate from upstream. In these case we like to add a URL to the upstream bug report.

• patch_or_code_attached [-+?]

There is either a patch or some code attached to this bug. Attached may actually mean inline in the text, but the bug contains some code change which someone says works for them.

• Review [-+?]

This bug/change needs review by someone else. This is used by the dev team for "Do you think this change is a good one?"

• [-+?]

Set the flag to ? to say someone needs to look at it

Bug Triage

If you can help do these steps, the developers can concentrate on fixing the bugs.
The steps in this list is maybe 90% of the time of most bugs.

Reread How to report bugs effectively

Now look at the bug reports in Bugzilla with your developer hat on.

• Go into triage mode
• Ask the questions asked by the essay
• Get the information from the reporter
• Reproduce the issue
• Confirm the bug or mark it invalid if you can't reproduce it
• Summarise the issue if the report isn't clear
• Add a note about a workaround/fix if one is obvious to you
• That fix may not be the one we adopt, but it often helps if you tell us what you did to fix it