pCDN:Bugreport

We use the NSL Bugzilla system to manage bug reports. We encourage all users to submit bug reports, which help us to improve our software quality. Bug reports should contain enough information to help engineers on identifying root causes. Insufficient details render bug reports useless. This page presents the info saved in our bug report system.

A new bug report must contain the following info:

• Project: possible value is pCDN.
• Version: release number.
• Component: possible values are server, client, monitor, importer, other.
• Severity: possible values are 1, 2, 3, 4.

1. Bug causes operating system crash or frozen.
2. Bug affects major functionality, which prevent users from downloading podcasts.
3. Bug affects minor functionality, where users can still download podcasts.
4. Bug contains typos, unclear wording, or potential GUI improvement.

• Reproducible: possible values are always, intermittent, never.
• Reproducible steps: (if applicable).
• Log files: attach log files (log.xml for the client, server.log.* for the server).
• Conf file:: attach conf file (conf.xml for the client, setting.ini for the server).

New bug reports are assigned to one of our engineers. He/she will review the submitted info and forward individual reports to appropriate engineers. In a few cases, we have to request for more info from you while resolving the bug. The following info is controlled by NSL engineers for coordination and documentation.

• Priority: possible values are 1, 2, 3, 4, 5.

1. Bug must be fixed immediately. It is blocking further development.
2. Bug should be fixed before the next release.
3. Bug is fixed if time permitted. Bug is trivial. Fix is not blocking the next release.
4. Not a bug, but is considered as a new feature.
5. Not a bug, the software functions as designed.

• Test Cases: contains at least one test case. Setup should be clearly described.
• Solution: describes the root cause, the proposed solution, and the list of changed files.
• Patched Version: indicates the version that contains the latest proposed solution. The version can be either (in preferable order):

1. A release number, such as 1.1 or 2.0.
2. A daily build number, such as daily-080130. Daily builds are generated using a cron-like utility on nsl-win. (Note: a script should be developed)
3. A svn command that can be used to check out the proper version on Linux. For Windows users, an equivalent instruction using tortoise can be used as well.

• Validation: documents the results of test cases. In case of multiple tests were performed, the date of each test should be given.