Intro to Bug Trackers (Activity)
Intro to Bug Trackers
Learners will gain an understanding of the features of bug trackers and how they are used to identify work items to be completed in a FOSS project.
|Learning Objectives||After successfully completing this activity, the learner should be able to:
|Process Skills Practiced|
Bug tracking systems are a tool for change management and organization used by FOSS projects. Bug trackers do far more than simply keep track of bugs. They also are used to hold new feature requests, patches, and some tasks. Bug trackers are also called request trackers, issue trackers, request trackers and ticket systems. Please read the two readings below for a more complete treatment of bug trackers and their use in FOSS projects.
We will begin by looking at a typical Bugzilla instance for a project. We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team.
Part 1 - Bug Reports
PART 1 – BUG REPORTS 2. ID stand for bug identification number. SEV stand for Severity and it is used to determine how severe the bug is, or whether it’s an enhancement. The range of values is from blocker to enhancement. Pri stand for Priority and an Engineer used to prioritize their bugs using this field. The range of values is from immediate to Low. OS stand for operating system and it is the OS the bug was observed on. The range of values is from All to Other. Product : categorised bugs into products and components. The range of values is from gjs to seed. Status: is used to determine the number of state of a bug. The range of values is from New to Verified. Resolution: is a conditional statement used to verify If a bug is in a resolved state or not , then other reasons will be given for its resolution. The range of values is from Incomplete to No TXIMIAN. Summary : The bug summary is a short sentence which succinctly describes what the bug is about. 3. I discovered the definitions of the column name in 2 above after clicking on the search after the browse and then hover my mouse over each field label. 4. The bugs are initially displayed as below ID Product Comp Assignee Status Resolution Summary Changed
5. Red: Bug 782877 – [Regression] Defaults for signing and Encrypting all messages are ignored for some accounts. All the fields’ record is in red colors. Gray: Bug 782774 – kmssink: drop last rendered buffer on ALLOCATION and DRAIN queries. All the fields’ record is in gray colors. Black: BUG 782829 – on a virtual machine(Virtualbox), gedit cannot safe opened files on the shared folder. All the fields’ record is in black colors. 6. Bug 764211 1. Bug was submitted on 2016-03-25 by Mortem Welinder 2. Recent discussion on the bug is the lack of transport layer encryption and the Simple mail transfer protocol(SMTP) used by the GNOME contributor is not supporting transport layer session (TLS) 3. The bug is current 4. The bug is assigned to GNOME sysadmins 5. I will write a code to encrypt the mail
Part 2 - Collective Reports
- Click on the “Reports” link on the top of the page.
- Click on the "Summary of Bug Activity for the last week".
- How many bug reports were opened in the last week? How many were closed?
- What was the general trend last week? Were more bugs opened than closed or vice versa?
- Who were the top three bug closers? Why is this important to know?
- Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists?
- Who are the top three contributors of patches?
- Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers?
- Click on the “Generate Graphical Reports” link.
- Plot a line graph of the severity of bugs by component for Orca:
- Select "Severity" for the vertical axis
- Select "Component" for the horizontal axis
- Select "Bar Graph" for type of graph
- Leave the "Multiple Images" as <none>
- Scroll down and select Orca from the Product menu.
- Click "Generate Report".
- What class were the majority of the bugs for braille?
- What other reports can you generate?
POSSE: On your user wiki page, a section describing the results of your exploration below.
Notes for Instructors
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.
- How will the activity be graded?
- How will learning will be measured?
- Include sample assessment questions/rubrics.
|Criteria||Level 1 (fail)||Level 2 (pass)||Level 3 (good)||Level 4 (exceptional)|
|The purpose of the project|
|Why the project is open source|
- What should the instructor know before using this activity?
- What are some likely difficulties that an instructor may encounter using this activity?
| ACM Body of Knowledge
Area & Unit(s)
|Environment / Materials||
Access to Internet/Web and web browser.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Suggestions for Open Source Community:
Suggestions for an open source community member who is working in conjunction with the instructor.