Today focused primarily on the lifecycle of bug reporting and the importance of a well prepared and written bug report. It can be the difference between having your issue taken care of quickly or ignored. We focused in on two specific bug trackers, Bugzilla and Trac. Bugzilla being older and more robust, Trac was newer and more lightweight.
I've used Trac before for some of my own projects, but today was the first time reporting a bug for someone elses project. The other main objective for the day was to hack apart some of the Sugar activity 'Measure'. We dove into the bug list on Trac looking for some relatively easy bugs we could start off with. Some of the first few we found had been completed already. It turns out that one of the maintainers, Walter, had been making and commiting changes that afternoon. After updating our codebase we dove right back in to try and solve an issue with the whole activity becomming unresponsive and crashing after capturing data. Some of the steps we took to begin work were:
* reproduce the bug as stated in the ticket
* search through open and related tickets for information others had reported
* asked for additional information on irc
* captured and posted log files to trac to help others with the issue.
* generated and pushed patches for errors we found
We were unsucessful with solving the actual crash bug by the end of the session. However we learned a lot about the activity and the process flow for reporting/assisting/fixing bugs. In the process of hunting the root cause of the crash bug, several other bugs were found or fixed. Some of the bugs were new discoveries and others were already documented bugs we updated or patched.
I am interested to see what new tools we will be using and learning tomorrow.