Bug Exercises Part One

While working on the team bug to be submitted Monday, each of us needed to complete some exercises in our open source online textbook. These exercises correlate directly with our team’s project and will prove valuable in becoming better at managing open source projects.

6.4 Find the oldest bug that’s still open in your chosen project. Write a blog entry describing the problem, with a theory about why the bug hasn’t been resolved yet. (Bonus points if you can actually resolve the bug.)

There is a bug that is 6 years and 27 weeks old. The bug is with the bug reporting system itself within a drupal project. Each bug can be classified in various ways. When it is classified as “patch (ready to be committed)” the bug is removed from the issues list. The bug was resolved in the comments but left open because of other issues discussed within the comments.

6.5 Figure out how to create a new account on the bug tracker of your chosen project. You’ll need that account very soon.

I had actually created an account a few days ago to post about a bug I saw. The name of the account is steveo1490.

6.6 Go through your project’s bug tracker and find a bug that you think you might be able to reproduce — and then try to reproduce it in the latest build. Take careful notes. Report your experiences as a comment to the bug. If you can reproduce the bug, great! Give as much information as you can. If you can’t reproduce the bug, great! Give as much information as you can, and ask the original reporter if there are other steps you might be able to take to reproduce the bug.

A bug I was working on this past weekend I was able to successfully reproduce. When in the administrative theme, the edit, add, revision, and delete pages will not come up properly if you change the lettering into anything other than all lowercase. I tried quite a few combinations such as Edit, EdIT, and EDIT. Each version did not show the administrative theme which shows the bug’s existence.

6.7 Find five bug reports in the newstate, and attempt to triage them according to the rules above. Your goal is to do as much as you possibly can, in a short period of time, to make those bug reports as useful as possible to the developer to whom they are assigned. (Note: be sure to follow any triage rules that your project may have defined. If there are no set triage rules, be sure to announce your intentions on the project’s mailing list, so that developers can provide you some guidelines if they choose.)

After reviewing some of the newer bugs. I noticed most of the bugs are triaged into the correct categories. The only slip ups I noticed that might make development and bug fixing more difficult is prioritizing. The Drupal bug tracker has four priorities: normal, minor, major, critical. Almost all new bugs were categorized as normal and some of the major bugs I looked at were either dupes, which I commented on and reduced the priority on, or were just not a functional issue. Being a nonfunctional bug lowers the priority down to at least the normal to minor level. I manged to change the priority on a few which I hope will give developers the right glimpse at what bugs need to be fixed now rather than later.

These exercises gave me a significant amount of experience with the bug tracker, as well as bug tracking organization. The triage techniques were also useful to learn, so I can use them in my future computer science projects that involve code maintenance. This Friday I will be posting about even more exercises that help foster my bug fixing talents.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s