|
Size: 2295
Comment:
|
Size: 2653
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 9: | Line 9: |
| == Bug squashing in debian == (Work in progress) |
== Bug Squashing in Debian == (A work in progress) |
| Line 32: | Line 33: |
| I have seen mail from Niko Tyne 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 [...] }}} |
|
| Line 41: | Line 54: |
| Line 49: | Line 59: |
## | CategoryAnother |
[:/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? Or do you use the web interface and search for specific bugs? If so, what are your filters and search criteria?
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 Tyne 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]