Added by Paul Cutler, last edited by Alexandre Franke on May 30, 2010  (view change) show comment

Labels:

issues issues Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

There are a few different ways of using FITS to manage issues and tasks.  This page will provide an overview triaging bugs, including searching for duplicates, closing issues or requesting more information from users to help with overall quality assurance.   This page focuses on bug and issue reporting, and not tasks in FITS.

A key to triaging bugs, is to start small.  Verify the bug, and add a comment.  Assign it to the correct developer if you know who that is.  Or just comment on the bug and ask the user for additional information.  Timely bug triaging will start to reduce the overall bug count before you know it. 

A heartfelt thank you from our users and developers for improving the quality of Foresight Linux! 

Please add additional tips and tricks you use to triage bugs. 

FITS Overview

Before triaging issues in FITS, please read the wiki page on how to create an issue and FITS overview. Please familiarize yourself with how a normal user would open a bug report in FITS.

Structure

The default behavior for assigning an issue when opened by a user, is to automatically assign it to the "Distro" user in FITS. This is the easiest and fastest way to see if a bug has been triaged, as it won't have been assigned to a specific developer yet.

Key developers

A number of developers are lead on specific parts of Foresight.  When assigning issues, a good default is:

  • Documentation:  Paul Cutler (pcutler in IRC or silwenae in FITS)
  • Xorg and Binary Video Card Drivers: Antonio Meireles (doniphon)
  • GNOME and it's default applications, such as Epiphany, Banshee, F-Spot or GIMP: Ken VanDine (kenvandine in IRC or ken in FITS)
  • Kernel: Justin Forbes (jforbes)
  • Security: Jonathan Smith (smithj)
  • Anaconda / installation issues:  Elliot Peele
  • PackageKit: Ken VanDine or Elliot Peel

If you don't know who to ask, please ask in #foresight-devel on Freenode IRC before just assigning it someone or ping a specific individual to see if they are willing to have it assigned to them.

Filters

There are a number of ways to start triaging bugs, feel free to pick one that you are most comfortable with:

  • Search through the list of all open bugs
  • Create a filter by severity type (Trivial, Minor, Normal, Major, Critical, Blocker)
  • Create a filter for bugs assigned to the default "Distro" user
  • Create a filter on a specific package name or topic (i.e., kernel, banshee, etc)

Creating a filter

FITS offers a powerful system for searching through issues, and let's you save filters you create to your profile, in addition to it's default filters.

On the front page of your dashboard on the FITS home page, you will see on the left each project, with default filters such as "All", "Outstanding" and "Added Recently".

On the right at the top, you will will see "Saved Filters", including links for "Create New" (filter) and "Manage Filters" as seen in the screenshot below.

To create a new filter, click on the "Create Filter" link.

Here you have a number of options to choose from:

  1. Choose the project, typically Foresight Linux
  2. Issue Type, choose "Bug"
  3. Assignee, you can leave blank, or if you want to search for "Distro" as it is probably unassigned to a developer if it's still assigned to Distro, choose "Specify User" and in the next text field type "jira-distro".
  4. If you don't want to search for the Distro user, leave it on the Default, and in Status choose "Open".  (If you do choose to search Distro, search for "Open" bugs as well - you don't have to see closed bugs if you don't want to!)
  5. Click the "View" button located at the upper left under the navigation bar.  You can also choose "View and Hide" but if you're new, leaving the View open will let you re-run your query if you get unexpected results.
  6. Another helpful filter is to create one using date ranges.  It is sometimes helpful to close newer or older bugs depending on your level of experience

Verifying the bug

This is the most important part of bug triaging.  Can you verify the bug actually exists?  When trying to duplicate the issue, please keep in mind:

  • Are you running the same version of Foresight Linux as the user?
    • Have they done a recent updateall?
    • Are you running the development version? 

Especially with older bugs that may still be open in FITS, a newer version of Foresight Linux or the specific package can correct the issue.  With Foresight on a rolling release schedule, there are times when a user may not have performed an updateall recently.  Adding a comment to an issue to ask the user to verify the version or try to upgrade may help resolve the issue.

If you can't verify the bug, or have a suggestion for the user, leave a comment.  Be specific in your comment of what information you need from the user, whether they can paste it in to a comment, or by attaching a file.  By leaving a comment, you are helping the QA team in a number of ways:

  • The user who files the issue will get an email that a comment has been added, hopefully prompting them to read it and take action
  • Documents that the bug has started to go through the triage process
  • An email is automatically generated to the Foresight Bugs list for developers to be aware of

Even if you take no additional steps as outlined below, and comment on the bug, similar to "I can confirm this bug on Foresight Linux 1.4" helps immensely.  This saves developers a step in verifying the issue, and they can move on to trying to fix it.

Duplicates

Another important aspect of bug triaging, is finding duplicate bug reports for the same issue.  The older issue should always be kept as the original issue, and any new issues opened should be marked as "Resolved" - "Duplicate" per the Editing an Issue section below.  By marking an issue as a duplicate, you will be asked for the original issue number to link the issues together. 

Editing an Issue

Once a bug has been verified, the next step is to review the bug and assign a developer.

Things to look for:

  • Is the issue filed correctly as a bug, and not a task for example.  (Or should it be an improvement, and not really a bug?)
  • Is the priority marked correctly?  There is a judgement call to be made, but Banshee not playing AAC files may not be a critical issue when you take a step back and look at Foresight as a whole operating system, as an example.
  • Is the correct version of Foresight Linux assigned?  Did the user mention in the bug report what version they were running?  (1.3 vs. 1.4 as an example)

Updating an issue status (Duplicate, Resolved, Will Not Fix, etc)

After verifying the bug exists, and a fix also exists, it is customary to comment on the issue first asking the user who filed the issue to apply the fix.  Once you have confirmation from the user, or if the user doesn't respond after a set amount of time, ask other users in IRC to verify if the fix works for them.

To change the issue status, click on "Resolve Issue" on the left.

The seven resolution codes to close an issue are:

  • Fixed:  The bug is fixed due to an upgrade in software, a patch, new version, etc
  • Won't Fix: Usually applied to improvement requests, very rarely to bugs
  • Duplicate: See above in the "Veryify a Bug" section
  • Incomplete: Used rarely, after being commented for more information and the user doesn't reply after months and no one else reports the issue.
  • Can't Reproduce: Similar to Incomplete, the person triaging bugs should comment in the issue how they tried to reproduce the issue.  Also ask others in IRC if they can reproduce.  Always ask the user for more information and give them time to respond before marking as Can't Reproduced.
  • Invalid: Used rarely, when an issue is not filled out correctly.

When an inssue is marked as resolved, the user who originally filled out the issue and the developers will get an email with the update. 

Filing bugs upstream

One of the founding principles of Foresight is to give back to the communities and developers who created the software used in Foresight Linux.  When a bug is confirmed as a problem with a package and not due to the way it is packaged in Foresight Linux, it is important to let the developers of the software know of the issue, and of a potential fix if one exists.

This includes software from Xorg to F-Spot to Avant-Window-Navigator.  When filing a bug upstream, please cross-reference the Foresight Issue number in FITS as well.

Upstream bug repositories include:

Thank you

Thank you for taking the time and helping to improve Foresight Linux.  Having a rolling release schedule helps our users in keeping their systems up to date, and provides bug fixes for software, but even then sometimes issues come up that users need help with.  Verifying bugs, and helping developers fix those bugs makes the user experience that much better for everyone.