Reporting a bug — with guest blogger Maynard Demmon!
Getting a bug fixed on an open source project can be a frustrating experience. Learning enough about the codebase to fix the bug yourself may not be something you have the time or expertise to do. To increase the odds that your bug will be addressed you want to make it as attractive to the developers as you can.
One of the best ways I've found to make a bug report attractive is to provide a clear and concise test case. In a GUI application this might be a sequence of steps to reproduce the bug. With a development platform like Laszlo a test case is the simplest piece of code that consistently demonstrates the bug.
The key words here are simple and consistent. The test case needs to be as simple as possible so the developer can quickly focus in on the problem and consistent so that the developer can be sure that their changes actually fix the bug. When providing a test case for in a Laszlo bug report you
should keep the following things in mind:
- The test case should be a complete application. Included everything between the opening and closing <canvas> elements. A developer shouldn't need to write additional code to get the test case to run.
- Collapse the test case into the minimum number of files needed to reproduce the bug, ideally 1 file. This includes dependencies on assets such as fonts, resources, external datasets, etc. A developer doesn't want to have to pull down and manage a bunch of different files from the bug tracking system.
- Make sure any commentary provided in the test case is inside an XML comment tag. A developer shouldn't have to snip out the relevant parts of the test case from a sea of commentary about the bug.
- Simplify the test case as much as possible. Remove everything that is not needed so that the developer can focus in on what is not working.
- If you can construct code that is very similar to your test case that does work correctly provide that in the test case as well. For example maybe a bug only shows up if you use a $once constraint but not with a $ constraint.
- Provide precise details of the environment within which the bug occurs. This should contain the following:
- The operating system.
- The web browser name and version number.
- For SWF the version of the flash player.
- The version of the LPS used to compile the test case.
- Any parameters used during compilation such as lzr=swf8, debug=true, etc.
- The version of the java runtime the LPS was using.
Maynard Demmon is a Laszlo Systems developer. Maynard has filed some great bugs with the right amount of detail and easy test cases, making them a breeze to fix. See, for instance, LPP-4370, drawview doesn't respect visibility








