You are here

Improved Bug Tracking Tool

Project ID: 
183
Current stage: 
Manager: 
What: 

Description: This project will deal with providing an improved bug tracking tool for use wihin the School of Informatics.

Deliverables: An improved bug tracking tool, available as a full service to users, with LCFG config, documentation and service catalogue entry. Technical talk on the subject.

Why: 

Customer: School

Case statement: The Bugzilla bug tracking tool currently in use within the School has proved useful on many occasions, particularly when managing OS upgrades but the version we are currently using is out of date and contains a large number of dated tickets. We need to establish whether any of these tickets are still relevant and whether more recent versions of Bugzilla or indeed a different bug tracking system would be more suitable for the School's needs.

When: 

Status:

Timescales: 1 week to review available systems and collate report
2 weeks to install and configure selected test systems and select most suitable for our needs.
Identify active tickets and if relevant test porting them to the new systems
2 weeks Install full LCFG-based service
1 week Documentation and Final report
Total - 6 weeks

Priority: 2

Time:

How: 

Proposal: Since this project was first conceived MPU have moved most of the bug tracking for LCFG components to a separate bugzilla server and RAT have a Trac installation. The main bugzilla.inf.ed.ac.uk server is under utilised and out of date. The feeling amongst COs, however, is that there is a requirement for a bug/issue tracking service for the next major OS upgrade. If we stick with bugzilla at the very least we should move to version 4.4, update the LCFG component and clean out the cruft.

The new features in Bugzilla v4.4 will offer more scope for providing a bug/issue tracking service for general Informatics use. These should be investigated and tested.
A further examination of possible requirements from C(S)0s using the existing system and general School users current or planned use of bug tracking will be used to inform the project.
More modern systems offer integrated issue tracking, source code control and wiki features. Some are available as free or paid web services. Investigating the features of these systems will give us some clues about current best practice to help choose a suitable replacement for the existing buzilla.inf. Ideally any solution should be FOSS. Finally having decided on a candidate it should be installed as a full service.

Resources: Knowledge of Bugzilla. VMs for testing systems.

Plan:

  • Survey
    • Consult with C(S)Os using the current system / LCFG bugzilla and RaT Trac
    • Consult Research Institute/group heads, general userbase.
    • Review any previous requests for bug tracking in RT.
    • Establish potential candidate systems, desirable features, commercial/FOSS etc
    • Collate Report
    • Select test systems
  • Installation and Testing (dependent on the above)
    • Establish Test criteria
    • Install / test version of Bugzilla v4.4.2
    • Install / test version of e.g. Apache Bloodhound
    • Test porting of existing bugzilla ticket to new systems
    • Select final candidate
  • Full Service Installation
    • LCFG component - update lcfg-bugzilla or new component
    • Apache config
    • Database config
    • Cosign testing
    • etc
  • Completion and sign-off
    • User docs
    • Administrator docs
    • Service Catalogue entry
    • Final report
Other: 

Dependencies: Ease of transferring active tickets to the new system may be an issue

Risks: the same ones usually associated with any LAMP type system. Would it need to be world accessible? Is it currently? Use by iFriend collaborators?

Milestones

Proposed date Achieved date Name Description
5/2/14 Start project Rewrite devproj entry for project 183 and agree scope of project with CS/AS. Formally start project.
21/2/14 Survey Conduct requirements capture.
Research other issue tracking software and available features and collate a brief report on the pros and cons of each one, including features available only in commercially available software for comparison. Decide on test systems.
14/3/14 Installation and Testing Install and configure chosen systems. Test functionality and the possibility of porting existing tickets to new systems etc.
14/3/14 Proposal Propose best fit system
21/4/14 Full Service Implement full service including server configuration, creation of LCFG component to configure and run system (if required) and authentication/authorisation mechanism fully integrated with School's infrastructure. Migrate existing tickets to new system if necessary.
2/5/14 Project completion Produce user documentation and final report. Bring project for sign-off.