Bug Tracking Process

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

1. Bug arrives as follows

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

2. One of us triages the bug. This can result in the following outcomes
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 -> Component: something
 * probably a bug in VASSAL -> Component: something
 * probably a bug in VASL -> Product: VASL
 * probably a module bug -> Product: Other modules (I would recommend avoiding this--VASSAL should never dump a stack trace--even for a missing image file it should be able to use a placeholder image rather than dumping stack.)
 * 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".

3. We only get here if it was a bug in VASSAL and therefore is Status: NEW, Component: something
We assign the bug to ourself to work on -> Status: ASSIGNED

4. We fix the bug.
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)