Difference between revisions of "Bug Triage"

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
(note problem in instructions)
(Updated to reflect the use of JIRA for issue tracking.)
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
{{Breadcrumb|Table of Contents|Quality Assurance and Problem Reporting Guidelines|next=Joining the ADempiere Community}}
 +
[[Category:User documentation]]
 +
[[Category:Developer documentation]]
 +
 
Here we document the meaning of the priority levels assigned to reported bugs.
 
Here we document the meaning of the priority levels assigned to reported bugs.
  
 
== Where the bugs are ==
 
== Where the bugs are ==
  
−
[http://sourceforge.net/tracker/?atid=879332&group_id=176962&func=browse SourceForge Bug Tracker]
+
* [https://adempiere.atlassian.net/secure/Dashboard.jspa JIRA - ADempiere's Issue Tracker]
  
−
[http://sourceforge.net/tracker/?atid=955896&group_id=176962&func=browse SourceForge UI Tracker]
+
Legacy trackers:
 +
* [http://sourceforge.net/tracker/?atid=879332&group_id=176962&func=browse SourceForge Bug Tracker]
 +
* [http://sourceforge.net/tracker/?atid=955896&group_id=176962&func=browse SourceForge UI Tracker]
 +
 
 +
== 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.<br>
 +
#: For example you can try to reproduce the bug on the test site http://www.testadempiere.com/webui.<br>
 +
#: 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 <font color=red>'''priority'''</font> according to the [[#Priority|table]] described below
 +
### Assign <font color=red>'''group'''</font> according to the [[#Group|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.
  
 
== Helping with Triage ==
 
== Helping with Triage ==
Line 11: Line 46:
 
# Sign up to review a small section of bug reports, at the latest link underneath the heading Volunteering below.
 
# Sign up to review a small section of bug reports, at the latest link underneath the heading Volunteering below.
 
# Get the latest code/db.
 
# Get the latest code/db.
−
## use the ready-to-run NX client at [[www.testadempiere.com | testadempiere.com]] (hosted by [[www.idalica.com | Idalica]])
+
## use the ready-to-run NX client at [http://www.testadempiere.com/startdemo.html testadempiere.com] (hosted by [http://www.idalica.com Idalica])
−
 
+
## or use the ready-to-run zkwebui client at [http://www.testadempiere.com/webui testadempiere.com] (hosted by [http://www.idalica.com Idalica])
−
<!> NB> the following line of instruction does not have a live target at the other side -- RPH
+
## or download the daily adempiere binary from [http://www.testadempiere.com/startdemo.html testadempiere.com]
−
 
+
## or download and build the sources yourself, and apply all the latest migration scripts.
−
## download the daily adempiere binary from [[www.testadempiere.com | testadempiere.com]] 
+
−
## 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 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 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'  ;)
 
# If you can not reproduce the error, then close the bug, and say 'Works in latest version'  ;)
  
−
== How to Prioritize ==
+
== Priority Levels ==
−
 
+
−
The Project Management Committee has established guidelines for using the priority field in the SF bug tracker.  This was discussed in the PMC meeting of 03/06/2007, the notes are here:  [[CC_Meeting_Full_20070306]]
+
−
 
+
−
If you are filling out a report, you can assign priority and group according to the following guidelines:
+
−
 
+
−
=== Resolution ===
+
−
* Remind - In some cases, there is already a patch or code snippet in the bug report that has not yet been applied.  In these cases, set the Resolution to "Remind" and these can be looked at first on a bug day.
+
−
 
+
−
=== Priority ===
+
−
 
+
−
* [http://sourceforge.net/search/index.php?group_id=176962&words=group_artifact_id%3A(879332)+AND+priority%3A(9)+AND+status_id%3A(1)&type_of_search=artifact&pmode=0&limit=100 Priority 9] - system stopper - data corruption without workaround
+
−
* Priority 7 - security issues
+
−
* Priority 5 - not prioritized
+
−
* Priority 3 - problems with workarounds - performance problems
+
−
* Priority 1 - presentation problems
+
−
 
+
−
=== Group ===
+
−
 
+
−
It's very important also to assign the group for the bug:
+
−
* Beta - if you're reporting a bug over a beta functionality
+
−
* Core - if you're reporting a bug over a core functionality
+
−
* Module specific - if you're reporting affecting just a specific module (not core)
+
−
* Report - if you're reporting problems of presentation or reports
+
−
 
+
−
=== Release ===
+
−
 
+
−
From time to time, the bugs will be triaged to re-prioritize them according to these standards.
+
  
−
Priority and group are important, because we will not announce a stable release while there are known [http://sourceforge.net/search/index.php?words=group_artifact_id%3A%28879332%29+AND+priority%3A%289%29+AND+status_id%3A%281%29+AND+artifact_group%3A%28%22Core%22%29&group_id=176962&type_of_search=artifact&pmode=0&limit=100&offset=0&sort=open_date&sortdir=desc priority 9 bugs on core].
+
If you are filling out a report, you can assign the priority according to the following guidelines:
  
−
==Volunteering==
+
* Blocker - Blocks development and/or testing work, production could not run.
−
===[[Triage December 2007]]===
+
* 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.

Latest revision as of 20:54, 28 February 2012

⇐ 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.

Where the bugs are

Legacy trackers:

Explanation of Bug Triage Process

Bug Triage is the process of reviewing a reported bug.

  1. 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:
    1. 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:
      1. Change resolution to Invalid
      2. Add a comment asking for better explanation and steps to reproduce
      3. 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.
    2. 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:
      1. Change resolution to Works for me
      2. 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)
      3. Change status to Pending
    3. Bug is reproducible in release repository:
      You find the bug is valid, so it's recommended that you:
      1. Change resolution to None. Or change the resolution to Remind in case the tracker has a proposed patch or solution.
      2. Leave status in Open
      3. Try to assign proper category in case it's not assigned
      4. 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.
      5. Assign priority according to the table described below
      6. 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.

Helping with Triage

  1. 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.
  2. Sign up to review a small section of bug reports, at the latest link underneath the heading Volunteering below.
  3. Get the latest code/db.
    1. use the ready-to-run NX client at testadempiere.com (hosted by Idalica)
    2. or use the ready-to-run zkwebui client at testadempiere.com (hosted by Idalica)
    3. or download the daily adempiere binary from testadempiere.com
    4. or download and build the sources yourself, and apply all the latest migration scripts.
  4. If you can reproduce the bug in the latest build, set the priorities as noted below.
  5. If there is not enough information to reproduce, then you can ask for more details.
  6. 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.
Retrieved from "http://www.adempiere.com/index.php5?title=Bug_Triage&oldid=7874"