Table of Contents

Starting Bug Triage

Last Modified Date: 03-08-2011

Author:Semen Cirit
Version:0.2

Choosing Bugs

Understanding Bugzilla

Bug Importance

We use four types of bug importances and give each a specific meaning and time interval:

Urgent:

Freeze, panics and crashes that reproducible on all type of systems and makes the whole system unusable and security related bugs. These bugs should fixed promptly.

High:

Bugs that are reproducible on all type of systems and makes the program unusable (packages which are totally unusable and have missing dependency, like being uninstallable or crashing on startup, bugs cause that cause loss of user data). These bugs should be fixed in 1 months.

Normal:

Bugs that are reproducible on all type of systems and makes a part of the program unusable. These bugs are probably be fixed in 6 months.

New feature:

New feature requests. These requests will probably be done for the next release.

Low:

The others - a cosmetic problem, such as a misspelled word or misaligned text or an enhancement, bugs that are not reproducible on all systems. These bugs are not schduled to fix in the next 6 months. This is not the same as planning not to fix the bug; it means that we don’t know when we will fix it, if at all.

Notes: Hardware specific bugs generally seemed as urgent, but it should be generally high. Because urgent severity is used when the entire distribution does not work, but a bug restricted to a specific hardware usually has a high severity.

Check list for bugs have NEW status

This checklist is used for bugs which have NEW status.

  1. Does the bug report mention about a real bug?

    • In some cases, users need some help about configuring or using software. These reports are not related with bug or feature request. These type of reports should be closed with RESOLVED/INVALID resolution, and a polite comment should be give in order to guide user to related forums or mail lists.

  2. Is the bug product and component right?

    • To take technical assistance please see Finding Correct Product and Component.
    • If the bug component is assigned to wrong, it should be changed.
    • In some cases, it is not possible to find correct component, until the source code is examined. In such a situation, you can take help from assigned developer.

  3. Has the bug a duplicate?

    • If so, the less informed bug resolution should be set as RESOLVED/DUPLICATE with bug number of the most detailed report and duplicate bug stock response is gived as a comment.

    • If it is not clear that a bug is a duplicate of another bug, please politeliy convince reporter with your comment.

    • For additional help: Finding Duplicate Bugs.

    • Also:
      • Observe Most frequently reported bugs.
      • Analyse the bugs assigned same component.
      • Use advance search for the bugs assigned different components and try to find similarities.

  4. Do the bugs depend each other?

    • If a bug fix helps another bugs resolution, or vice versa, please explain it with comments on each bug.
    • If you are sure about this dependence, add the number of the bug which should be fixed first to the other bug “Depends on” part.

  5. Are more then one bug is reported in one report?

  6. Is there enough information for developer to fix the bug?

    • If not,
      • Request for more information from the reporter (please be polite). Leave the bug status as NEW and state NEEDINFO as a keyword.
      • Please add your own idea to the comment. This idea generally comes into mind, while trying to reproduce the bug. Additionaly you can comment according to attachments.
    • Look Gather information from specific Bugs for necessary bug information:
      • Are the steps for reproduce explained clearly?
      • Were the relevant log files and outputs added to the report?
      • If a crash occured, did the stack trace is added?

  7. Do the summary helps the bug?

    • If the summary part is far away from the meaning of the bug or confusing, feel free to change it.
    • Please try not to change the idea of the reporter.

  8. Which severity should I use?

    During bug triage process, it is very important to state bug severity. Most bugs assigned with severity Normal, but the severity of the bug should change related to different bug importances.

  9. Is the bug a blocker bug? (For release tracker bugs)

    Only ongoing releases has tracker bugs. If a bug is a tracker bug of one of the ongoing release it should be fixed before the release time. When it did not fix, it delays the release. Therefore the bug numbers which has a power to block the release should be set to “Depends on” part of release tracker bug.

  10. How to resolve bugs?

    Many bugs can be fixed unintentially or by upstream. If you realised that the bug is fixed by an update, mark it RESOLVED/FIXED.

    When a bug fixed by its maintainers, the bug will be marked as RESOLVED/FIXED autmatically via commit messages.

  11. How to handle bugs in multiple releases?

    If you experience that a already reported bug is also reproducible for an other Pardus release, explain it as comment.

  12. How to reproduce or isolate the cause of the bug?

    In order to reproduce the bug there are two usefull questions to answer:

    • Is the bug due to a specific configuration or hardware?
    • Has the bug already been fixed?

    1. If it is a non-reproducible bug for the reporter, like a crash or intermittent failure:

      • Be sure the reporter system is up to date
      • If the reporter system is not up to date, you can offer the reporter up to date. (Some non-reproducible bugs can be fixed by updates)
      • Some specific configuration or hardware might be cause these type of bugs, so there is no guarantee than update will fix it. But running more recent code makes it more likely developers will track down the cause.

    2. If this is a reproducible bug for the original reporter, you can try to experience the bug yourself.

      • If it can be reproducible only for the release reaches its end of life, relove the bug as RESOLVED/INVALID.

      • If the bug can be reproduced for the stable and test repository release at the same time, this is evidence that the bug is not due to a specific configuration or hardware.

      • If the bug can be reproduced for the stable repository release but not for test repository release this is strong evidence that the bug has already been fixed. Give a bug comment that “this bug will be fixed after the package merges to stable”. You can resolve the bug as RESOLVED/FIXED

      • If the bug cannot be reproduced for the stable repository release, this is strong evidence that the bug is due to something different in the environment of the reporter.
        • Make sure that the reporter system is up to date
        • Make sure that you are using exactly the same method to reproduce the bug as the reporter.
        • If you suspect user specific operation, ,ask the reporter to create a new Unix user and try to reproduce with that user.
        • If you suspect machine specific operation, ask the reporter to try reproduction with reinstalling problematic package with moving any cached data or configuration files.
        • If you suspect a hardware-specific problem, you might request a information about the relevant hardware

  13. Has the bug already been reported to upstream?

    • Search the bug in the upstream Bugzilla or mailing list, if they exist.
    • If you find a report that has already reported to upstream, give UPSTREAM keyword and a link to Pardus bug report and leave the bug open.

    Upstream bug reporting systems:

Mark as triaged

If you finish triage, you should add TRIAGED keyword, in order to avoid retriage.

Pursuance

If you set a NEEDINFO keyword in a bug, you have to control the bug during 30 days if the reporter or other commenter give an additional information in order to reproduce the bug, you have to remove “NEEDINFO” keyword. If any user return the bug durin 30 days bug will automatically closed.

EOL Bug Triage

For bugs filed against Pardus releases that have reached their End of Life (EOL):

  • If the bug appears to be occurring in a more recent (non-EOL) version, update the version number and leave the bug open,
  • Otherwise, mark the bug CLOSED/WONTFIX and add the EOL stock response.

General Advice

  • Please be polite when triaging bugs; we need reporters in order to improve Pardus
  • Please try to reproduce the bug before requesting additional infor mation. Avoid requesting information and re-testing that isn’t really necessary; this is obviously frustrating for them.
  • Avoid marking a bug as a duplicate that isn’t really the same. If you don’t have the technical expertise to be certain, just add a comment with the other bug number, and say it’s a possible duplicate.
  • If the developer has commented on the bug or filed it themselves. Let the bug to developer, if more information was needed, they probably would have requested it themselves.
  • You can take help from test list
  • Add yourself to the CC: list of bugs you triage.
  • Please read carefully, and think before you click.
  • Use Bugzilla Stock Responses as appropriate.

First Steps to Contribute Triaging

  1. Track closely bugzilla mail list and read triaged bugs carefully.
  2. Take an account from Pardus bugzilla
  3. Read this document carefully :)

#. Write comments little by little to the bugs on bugzilla for triaging .. #. When you feel ready for triaging, please send a message to test list with your triaged bug ids, the experienced triagers will review your triaged bugs and approve your triaging request (At this point, you will take permissions for changing bug status, severity etc. to deeply triage).

Pardus® and Pardus® logo are registered trademarks of TÜBİTAK/UEKAE. Created using Sphinx 0.5.1.