|
Size: 641
Comment:
|
Size: 2653
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from BugSquashingPerl | |
| Line 4: | Line 5: |
| Describe in one or two lines what your page is about. | |
| Line 9: | Line 9: |
| == A more in-depth HowTo on bug squashing in debian == | == Bug Squashing in Debian == |
| Line 11: | Line 11: |
| === Sub title === | (A work in progress) |
| Line 13: | Line 13: |
| == Title 2 == | === 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 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] |
| Line 17: | Line 56: |
| ##See also: | ## See also: |
| Line 19: | Line 58: |
| ## CategorySomething | CategoryAnother | CategoryBugs |
[:/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 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]