Differences between revisions 12 and 14 (spanning 2 versions)
Revision 12 as of 2008-10-13 07:44:27
Size: 2653
Comment:
Revision 14 as of 2008-10-21 07:54:11
Size: 2820
Comment:
Deletions are marked like this. Additions are marked like this.
Line 23: Line 23:
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? 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?[[BR]]
Or do you use the web interface and search for specific bugs? [[BR]]
If so, what are your filters and search criteria? [[BR]]
Do you use external sources in different periods? i.e just before a release do you check [http://bts.turmzimmer.net/ RC bug list] for example?
Line 33: Line 36:
I have seen mail from Niko Tyne where he presents this code recipe: I have seen mail from Niko Tyni where he presents this code recipe:

[:DebianWiki/EditorGuide#translation:Translation(s)]: none

(!) [:/Discussion:Discussion]


Bug Squashing in Debian

(A work in progress)

A perl-centric workflow

In my time working with the [http://pkg-perl.alioth.debian.org/ debian-perl group] I have noticed that some of the team 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.

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??BR Or do you use the web interface and search for specific bugs? ?BR If so, what are your filters and search criteria? ?BR Do you use external sources in different periods? i.e just before a release do you check [http://bts.turmzimmer.net/ 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
[...]


Other useful bug triaging resources

BugTriage?BR [http://www.debian.org/Bugs/server-control BTS control]


CategoryBugs