Bug Triage

From ADempiere
Revision as of 12:14, 29 October 2009 by CarlosRuiz (Talk) (fix broken links)

Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

Here we document the meaning of the priority levels assigned to reported bugs.

Where the bugs are

SourceForge Bug Tracker

SourceForge UI Tracker

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 use the ready-to-run zkwebui client at adempiere.pmman.com (hosted by Russ Herrold)
    4. or download the daily adempiere binary from testadempiere.com
    5. 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'  ;)

How to Prioritize

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

  • 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 priority 9 bugs on core.

Volunteering

Triage December 2007