SquashUsSomeBugs

Plan for how to work on SquashUsSomeBugs

Created by: WaterDragon, Last modification: 13 Jun 2007 (14:19 UTC)

Plan of Attack against the bugs


The plan of attack for bug squash day is a three pronged attack against those vile bugs using roles. An individual may fill one or more rolls as they see fit.


Testers


Requirements


Each bug finder should have a browser (or two or three) with which to use a bitweaver install, an IRC client, and preferably a sourceforge account with which to report bugs.

Process


One aspect of bug squashing day is finding and documenting bugs.

To this end we have setup a number of test environments with the latest code from R2 CVS. Each environment has a complete bitweaver installation. All environments have both postgresql and mysql backends setup and have a script installed which allows one to wipe out either database as well as update the code to the latest CVS code. Each tester will be assigned to a particular test environment on which to work.

Testers, please logon to #bitweaver to get assigned to a test install.

Testing Installation

The first step is to make sure you have the latest code: Go to the management script for the domain given to you in #bitweaver

http://bugs1.domain.tld/manage.php

And run the CVS update and wipeout everything to make sure you have a clean envrionemnt.

The next step in finding bugs is to run through the installer. This should be done against a mix of both postgresql and mysql in order to try to find bugs against both database. Each install can be done against both postgresql and mysql in order to allow for testing against either database.

The username and password for all installs on the test systems is bitweaver. Each install has access to databases named after the first portion of the install domain. So bugs1.domain.tld should use the database name of bugs1. So for bugs1 the installer should use:
Username: bitweaver
Password: bitweaver
Database: bugs1

Finally, please do not turn on auto submission in the installer as this sends a flood of emails that we do not want in testing.

Testing Packages

The next step in finding bugs is to test packages. For each package we are going to ship we should tweak every knob and try every setting against both a postgresql install and a mysql install of the package.

Reporting Bugs

Bugs found should be documented on our sourceforge bug tracker. Please include in the documentation which browser you were using.

Resetting an install

It is possible to reset an install using the management script provided by management.php on each installation. From this interface it is possible to wipe out the database, wipe out the config_inc.php and update the code to the latest from CVS. Please do not reset an install the is not your assigned test installation. You can also view the servers logs if you need to.

Exterminators


Requirements


Exterminators should have a clean CVS install with which to work on. These should be on the exterminators own system. Exterminators must have commit access to CVS in order to send in patches to the system.

Process


All bugs must be squashed! To do this each bug squasher needs to have a clean CVS installation of bitweaver to edit and test with on their own machine. Developers should select a bug and announce which bug they are working on in #bitweaver in order to avoid duplicating work on the same bug. The bugs should be selected from sourceforge and squashed. If you need help figuring out where to look for a bug or how to fix it please ask on IRC. When you believe you have squashed the bug please commit it to CVS and announce the URL for the sourceforge bug on IRC for a coroner to test.

Coroners


Requirements


Same as for testers except ideally coroners should have the rights to close out bugs on sourceforge.

Process


Coroners are responsible for confirming that a particular bug is dead. Ideally the coroner for a particular bug will be the Tester who found the bug in the first place. When a bug is announced on IRC as dead the coroner is responsible for confirming that the bug is gone. If the coroner did not report the bug he should first confirm that he can reproduce the bug and then use the management.php script to update to the latest CVS version in order to get the patch and then confirm that they can no longer reproduce the bug. They should then announce the bug as dead on IRC. The bug will then be marked as fixed in sourceforge, preferably but the coroner.


Related Items

Documentation » Proposals and Requests

Things that haven't been implemented yet, but should be

  •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •  Anonymous