Bug Tracking Process

From VASSAL
Jump to: navigation, search

Below is the process we're following to manage VASSAL bugs.

A new bug arrives

Newly reported bugs will look like this:

  • Status: NEW
  • Product: VASSAL
  • Component: unknown
  • Version: unspecified
  • Platform: All
  • Importance: medium
  • Severity: normal
  • Assigned To: Joel

Note it would be very helpful if there were a way to auto-populate version and platform.

Someone triages the bug

Look at the stack trace at the bottom of the errorLog attachment. Based on what you deduce about the bug from the stack trace, change the bug as follows:

  • duplicate -> Status: RESOLVED, Resolution: DUPLICATE
  • bug in external library we cannot workaround -> Status: RESOLVED, Resolution: WONTFIX
  • bug in external library we can workaround -> Status: TRIAGED, Component: something
  • probably a bug in VASSAL -> Status: TRIAGED, Component: something
  • probably a bug in VASL -> Product: VASL
  • probably a module bug -> Product: Other modules
  • probably not a bug -> Status: RESOLVED, Resolution: INVALID (e.g. the user killed the process with the task manager)
  • can't reproduce the bug -> Status: RESOLVED, Resolution: WORKSFORME

Note that when choosing a component, have a look a few lines above the top of the stack trace. There you will see something like ...Vengine.jar VASSAL.launch.Editor or ...Vengine.jar VASSAL.launch.Player. If you see launch.Editor then set component to "Editor". If you see launch.Player above the bottom stack trace, then set component to "Player".

A developer is assigned a triaged bug

A developer decides to work on a triaged bug -> Status: ASSIGNED

The bug is fixed

Status: RESOLVED, Resolution: FIXED

The bugfix is merged into trunk

Status: VERIFIED

The trunk is released as a new version

Status: CLOSED, Target Release: (release version)