Translation(s): none

(!) Discussion


(A work in progress)

In my time working with the debian-perl group I have noticed that many group members have a remarkable ability to quickly reproduce and identify the cause of particularly nasty bugs. I thought I would try and find out how they go about doing this so I could become a better bug squasher for debian. This wiki page is my attempt to document the workflow and methods of some of those smart debian developers.

Firstly, one has to identify the bug. This can occur through various ways, but if you are member of the debian perl group you will receive bug reports on the packages that the group maintains. Tracking these bug reports in your mail client might be an efficient way of organizing an overview of the bugs in the group's packages, but there is also another effective tool, written in perl, called PET which stands for 'Package Entropy Tracker.' This tool tracks bugs reported to debian's BTS 'Bug Tracking System'

My aim is to ask this group of developers about their workflow, the tools they use, the work environment, and any other tips or tricks they have to make reproducing and closing bugs easier.

I am going to ask (and place here the replies to) these questions:

How do you identify new bugs?

Obviously bugs come in through the BTS, debian's Bug Tracking System. But do you read a mailing list of these bugs that is filtered in a particular way?
Or do you use the web interface and search for specific bugs?
If so, what are your filters and search criteria?
Do you use external sources in different periods? i.e just before a release do you check RC bug list for example?

Workflow

What specific procedure do you use for identifying bugs and putting them in your queue? Do you look for release critical (RC) bugs first? Do you prefer to tackle hard bugs or do you prioritize your work based on severity?

Testing environment

How do you reproduce bugs? Do you have a testing system or do you use a chroot environment on your own system? What does your testing environment look like? What is in your bag of tricks; the perl debugger? print statements?

I have seen mail from Niko Tyni where he presents this code recipe:

Here's a simple recipe, starting with a clean Etch chroot:

# apt-get install docbook-xml
# sed -i s/etch/lenny/ /etc/apt/sources.list
# apt-get update
# apt-get -d install perl-modules docbook-xml
# cd /var/cache/apt/archives
# dpkg --unpack perl-modules_5.10.0-*.deb docbook-xml_4.5-5*.deb
[...]

Another way to test code snippets or search for bugs is to use a 'repl' (Read Evaluate Print Loop). There is package that contains a repl in debian called libdevel-repl-perl, more info on that package here. The repl allows you to enter perl code and receive information back from the perl interpreter. This means you do not have to create a script to test your code, you can just drop into the repl. The most trivial repl available is this script;

use Devel::REPL::Script 'run';

Once you have that in a file, make it executable and run it. It drops you into a shell which evaluates your code through the perl interpreter. For example you could do this; (The dollar signs are the prompt from the repl.)

$ use Test::File;

$ use Test::More tests => 1;
1..1

$ file_exists_ok('/etc/passwd', 'Yup, its there.');
ok 1 - Yup, its there.
1

You can see that below the lines I input, that is the lines with the dollar sign prompt, the perl interpreter spits out the evaluation of that line. So when you input Test::More tests => 1; it says 1..1 just as the shell would if you ran this as a script. This allows you an excellent, and quick environment to execute some suspect code and see what it does.

Perl also has a debugger, though that is not widely known. It gets called with a perl -d and then you can give it a script name as well.


Other useful bug triaging resources

BugTriage
BTS control


?CategoryBugs