Bug Triage
From ADempiere
This Wiki is read-only for reference purposes to avoid broken links.
⇐ Table of Contents{{#if: Quality Assurance and Problem Reporting Guidelines| | Quality Assurance and Problem Reporting Guidelines }}{{#if: | | [[{{{3}}}]] }}{{#if: | | [[{{{4}}}]] }}{{#if: | | [[{{{5}}}]] }} | Bug Triage{{#if: Joining the ADempiere Community| | Joining the ADempiere Community }} ⇒
Here we document the meaning of the priority levels assigned to reported bugs.
Contents
Where the bugs are
Legacy trackers:
Explanation of Bug Triage Process
Bug Triage is the process of reviewing a reported bug.
- Try to Reproduce: You try to reproduce the bug on the latest release repository.
- For example you can try to reproduce the bug on the test site http://www.testadempiere.com/webui.
- As a result of your trial to reproduce one of these three things can happen:
- Bug is unclear:
- You can find that redaction of the bug is not clear enough to allow research of the problem, in this case it's recommended that you:
- Change resolution to Invalid
- Add a comment asking for better explanation and steps to reproduce
- Change status to Pending
- Note that Pending status will change to Closed if the user doesn't add comments in 14 days (configurable in sourceforge) or somebody else change the status back to Open.
- When the user that opened the tracker add a comment the status is changed back to Open automatically.
- Bug cannot be reproduced:
- When you find the bug is clearly explained but you cannot reproduce it in current release repository then it's recommended that you:
- Change resolution to Works for me
- Add a comment describing the steps you followed and stating that you could not reproduce the bug (possibly is an outdated bug, or reported for an old version)
- Change status to Pending
- Bug is reproducible in release repository:
- You find the bug is valid, so it's recommended that you:
- Change resolution to None. Or change the resolution to Remind in case the tracker has a proposed patch or solution.
- Leave status in Open
- Try to assign proper category in case it's not assigned
- Add a comment like "reproduced by _name_of_triager_". It's also recommended to add steps to reproduce when the tracker doesn't have them.
- Assign priority according to the table described below
- Assign group according to the table described below
- Please note that assigning correct priority and group are the MOST IMPORTANT steps of this process. With correctly triaged bugs we can plan better the stabilization of releases.
- For example you can try to reproduce the bug on the test site http://www.testadempiere.com/webui.
Helping with Triage
- Anyone can help. It is a matter of looking at bug reports, trying to reproduce in the daily build, then setting the priority of the bug.
- Sign up to review a small section of bug reports, at the latest link underneath the heading Volunteering below.
- Get the latest code/db.
- use the ready-to-run NX client at testadempiere.com (hosted by Idalica)
- or use the ready-to-run zkwebui client at testadempiere.com (hosted by Idalica)
- or download the daily adempiere binary from testadempiere.com
- or download and build the sources yourself, and apply all the latest migration scripts.
- If you can reproduce the bug in the latest build, set the priorities as noted below.
- If there is not enough information to reproduce, then you can ask for more details.
- If you can not reproduce the error, then close the bug, and say 'Works in latest version' ;)
Priority Levels
If you are filling out a report, you can assign the priority according to the following guidelines:
- Blocker - Blocks development and/or testing work, production could not run.
- Critical - Crashes, loss of data, severe memory leak.
- Major - Major loss of function.
- Minor - Minor loss of function, or other problem where easy workaround is present.
- Trivial - Cosmetic problem like misspellings or misaligned text.