1.1 Basic Questions

Roles in an Issue Tracking System

• Users (internal or external to the project team) report problems

• Project administrators prioritize problems and assign some to project staff

• Project staff report on status of problem solution

---

What Questions Does an Issue Tracking System Answer??

• What problems are currently open?

  • Is anyone working on these problems?
  • What’s their status?

• Which of those are the most severe?

• Have similar problems been reported in the past?

---

What is tracked?

• Which release(s) does the problem occur in?

• What are the environmental factors?

  • Operating system
  • 3rd party software

• Problem history

  • Can the problem be reproduced? How?

• Expected behavior

• Observed behavior

---

Open Alternatives

• Bugzilla was one the earliest well-known such systems

  • Defined much of the feature set and organization still used by its successors

• Commonly integrated into Forges to take advantage of infrastructure already provided for project management

  • particularly personnel mgmt.

2 Bugzilla

• Originally for Mozilla/Netscape project (1998)
  • Major updates have continued through 2011 (v4.0)

---

Bugzilla Problem Report

 

---

Bugzilla Classifies Problems by

• Severity

  • Blocker (a.k.a Showstopper): blocks development or testing
  • Critical: crashes, loss of data
  • Major: loss of important functionality
  • Normal
  • Minor: minor functionality loss and/or a workaround is available
  • Trivial: e.g., misspelled messages
  • Enhancement: request for new features

• Priority

  • Numeric, assigned by project managers

---

Bugzilla also Tracks

• Comments (forum-style)

• Notifications desired

---

The Life-Cycle of a Problem

 

---

What Goes into the System?

• Problems can be reported by end-users or team members

• Team members will generally not enter simple test failures

  • “Test cases make problems reports obsolete”
  • Unless the fix is outside their personal area of responsibility or they want someone else to step in

• Team members may use to track ideas and feature requests

• Already provide personnel management

• E.g., FusionForge provides separate tracking of bug reports and feature requests

  • Provides for attachment of files (test cases)
  • Assignment of a report to a project member generates a task in that person’s to-do list
  • Can track scm commits that fix problem via Tracker links on SCM pages

• Compare to our own Gitlab

Other Possibilities

• Search capabilities vary widely

• Some systems link problem reports to regression tests

• More general project task managers exist

  • E.g., Agile developers allocate “stories”

4 Eclipse - Mylyn

• Personal & shared task manager for Eclipse

  • Generally included with most programming language support packages

• Mylyn supports two kinds of tasks

  • Local tasks, stored in the Eclipse workspace
  • Shared tasks, from an issue tracking system or project task manager
    • e.g., Bugzilla, github, FusionForge

• Mylyn distinguishes between due dates and schedule dates

---

MyLyn and Project Perspectives

1. personal task list, including Bugzilla reports

2. Change set related to task

3. Task editor

4. Context-based task info

---

Working with an Issue-Tracking System

• Add a connector to the issue tracker
  • GitLab connector at Eclipse update site http://pweingardt.github.com/mylyn-gitlab

• Define one or more queries indicting what issue reports you want to be displayed by mylyn

  • E.g., in OurProject, display all reports assigned to me as tasks

• Select a task to update info (will synchronize with remote manager)

  • Or create new tasks

Task List

• Can display by category/query or by date

  • Searching & filtering are possible
  • “Focus on work week” option

• Color changes indicate scheduling & status

  • red for overdue tasks
  • blue for tasks scheduled for today
  • black for tasks scheduled for later in the week
  • green for tasks completed today
  • grey for tasks completed earlier

Context Management

• The context of a task is the collection of files & information related to the task.

  • E.g., Java files related to a bug
  • Changes made in the course of fixing it

• When you activate a task, Eclipse/Mylyn tracks the context

• The Focus on Active Task button causes the package explorer to show only elements in the active task’s context

Establishing Context

• From the task list, activate a task.

  • The package explorer switches to “Focus on Active Task” mode
    • If you are starting work on this task, this is empty
    Clear by releasing the Focus on Active Task button or alt-clicking to expand an element in the explorer tree.

• Start working

  • As you open files directly from the package manager, or indirectly (e.g., using Show Declaration (F3), Open Type (Ctrl-Shift-T), or Show References (Ctrl-Shift-G), they are added to the focused package manager view.

Restoring Context

• You can deactivate the currently active task (or activate a different task that you want to switch to).

  • Your various open editor windows close and the package manager returns to its normal unfocused state

• You “return” to a task by re-activating it.

  • Your editor windows for that task context are restored

Contexts and Tests

• You can create a Context Test Suite of those JUnit tests that you will be frequently re-running as you work on your active task.

Contexts and Change Sets

Changes made while working on an activated tasks are checked

• Change sets can be manipulated in the synchronize view
  • CVS & Subversion
  • Said to work with Egit, but I’m not seeing it in practice

Machine Hopping

• A major limitation (IMO) of the Mylyn context support is its limitation to a single workspace

  • I frequently work on the same project on different machines (office and home)

• Things I have yet to try

  • Exporting and importing of tasks
    • Not clear if context is included
  • Changing the task list data directory to a dropbox folder