DOCSLIB.ORG

Improving the Quality of Bug Data in Software Repositories BILYAMINU

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Improving the Quality of Bug Data in Software Repositories BILYAMINU Improving the quality of bug data in software repositories A thesis submitted as partial fulfilment of the requirement of Doctor of Philosophy (Ph.D.) by BILYAMINU AUWAL ROMO Computer Science Department Brunel University London Friday 15th April 2016 Abstract Context: Researchers have increasingly recognised the benefit of mining software repositories to extract information. Thus, integrating a version control tool (VC tool) and bug tracking tool (BT tool) in mining software repositories as well as synchronising missing bug tracking data (BT data) and version control log (VC log) becomes of paramount importance, in order to improve the quality of bug data in software repositories. In this way, researchers can do good quality research for software project benefit especially in open source software projects where information is limited in distributed development. Thus, shared data to track the issues of the project are not common. BT data often appears not to be mirrored when considering what developers logged as their actions, resulting in reduced traceability of defects in the development logs (VC logs). VC system (Version control system) data can be enhanced with data from bug tracking system (BT system), because VC logs reports about past software development activities. When these VC logs and BT data are used together, researchers can have a more complete picture of a bug’s life cycle, evolution and maintenance. However, current BT system and VC systems provide insufficient support for cross-analysis of both VC logs and BT data for researchers in empirical software engineering research: prediction of software faults, software reliability, traceability, software quality, effort and cost estimation, bug prediction, and bug fixing. Aims and objectives: The aim of the thesis is to design and implement a tool chain to support the integration of a VC tool and a BT tool, as well as to synchronise the missing VC logs and BT data of open-source software projects automatically. The syncing process, using Bicho (BT tool) and CVSAnalY (VC tool), will be demonstrated and evaluated on a sample of 344 open source software (OSS) projects. Method: The tool chain was implemented and its performance evaluated semi-automatically. The SZZ algorithm approach was used to detect and trace BT data and VC logs. In its for- mulation, the algorithm looks for the terms "Bugs," or "Fixed" (case-insensitive) along with the ’#’ sign, that shows the ID of a bug in the VC system and BT system respectively. In i addition, the SZZ algorithm was dissected in its formulation and precision and recall analysed for the use of “fix”, “bug” or “# + digit” (e.g., #1234), was detected when tracking possible bug IDs from the VC logs of the sample OSS projects. Results: The results of this analysis indicate that use of “# + digit” (e.g., #1234) is more precise for bug traceability than the use of the “bug” and “fix” keywords. Such keywords are indeed present in the VC logs, but they are less useful when trying to connect the development actions with the bug traces – that is, their recall is high. Overall, the results indicate that VC log and BT data retrieved and stored by automatic tools can be tracked and recovered with better accuracy using only a part of the SZZ algorithm. In addition, the results indicate 80-95% of all the missing BT data and VC logs for the 344 OSS projects has been synchronised into Bicho and CVSAnalY database respectively. Conclusion: The presented tool chain will eliminate and avoid repetitive activities in traceability tasks, as well as software maintenance and evolution. This thesis provides a solution towards the automation and traceability of BT data of software projects (in particular, OSS projects) using VC logs to complement and track missing bug data. Synchronising involves completing the missing data of bug repositories with the logs de- tailing the actions of developers. Synchronising benefit various branches of empirical software engineering research: prediction of software faults, software reliability, traceability, software quality, effort and cost estimation, bug prediction, and bug fixing. ii Contents 1 Introduction 1 1 1.1ProblemStatement................................... 3 1.1.1 MSR tools for VC log and BT data . 3 1.1.2 How to identify bugs (BT data) into VC log . 4 1.1.3 How to find discrepancies between VC system and BT system . 5 1.1.4 Syncing VC logs and BT data . 8 1.1.5 A framework for an automated detection and syncing of bug-related dis- crepancies................................... 9 1.2ResearchObjectives .................................. 9 1.3Thecontributionsofthisthesis . 11 1.4Thebeneficiariesofthisthesis . 13 1.5Structureofthethesis ................................. 14 2 State of the art 17 2.1 Introduction...................................... 17 2.2 Types of software repositories . 19 2.3 Definitionsandterms ................................ 21 2.4 Context ........................................ 22 2.5 Categories of research around bugs . 25 2.5.1 Bug triaging . 26 iii 2.5.2 Buglifecycle ................................. 27 2.5.3 Bugreporting................................. 29 2.5.4 Duplicatebugreports ............................ 31 2.5.5 Bugseverity.................................. 33 2.5.6 Bugtrackingsystem ............................. 33 2.6 Relatedtools ..................................... 35 2.6.1 Linkster.................................... 36 2.6.2 Relink..................................... 36 2.6.3 BucoReporter ................................ 37 2.6.4 Buco Analyser . 38 2.6.5 Bug Locator . 39 2.6.6 Bicho ..................................... 39 2.6.7 CVSAnalY . 40 2.6.8 Hipikat . 41 2.6.9 SoftChange . 41 2.7 Related techniques - SZZ algorithm . 45 2.8 SummaryoftheChapter............................... 46 3 Methodology 47 3.1 Introduction...................................... 47 3.2 Sampling an OSS forge . 47 3.3 Selecting the most appropriate VC system . 50 3.3.1 Distributed and Centralised VC system . 50 3.3.2 CVSAnalY . 52 3.3.3 Description of CVSAnalY schema . 53 3.4 Selecting the appropriate BT system . 55 3.4.1 Bicho ..................................... 56 3.4.2 DescriptionofBichoschema. 56 3.5 Locating VC logs and BT Data . 58 iv 3.5.1 Locating bugs in VC logs . 59 3.5.2 Locating bugs in BT data . 60 3.6 WorkedExample:Bracketsproject . 60 3.6.1 Identifying bugs in VC logs . 60 3.6.2 Brackets Project: Discrepancies between the bug sets from VC logs and BTdata.................................... 61 3.7 Automating and filling the missing data . 63 3.8 Summaryofthechapter ............................... 66 4 Locating bugs in VC Logs 67 4.1 Introduction...................................... 67 4.2 Definitions....................................... 68 4.3 Workedexample:Bracketproject. 69 4.3.1 Obtaining the complete set of bug IDs . 69 4.3.2 Evaluating the precision of each SZZ component . 71 4.4 Replicability and scability of the approach . 73 4.5 Trade-offbetweenrecallandprecision . 75 4.6 Replication with a large sample of OSS projects . 76 4.7 Summaryofthechapter ............................... 78 5 Discrepancies between the bug sets from VC logs and BT data 80 5.1 Introduction...................................... 80 5.2 Background...................................... 81 5.3 Results-OverallsampleofOSSprojects. 84 5.4 Scenarios of bug coverage . 89 5.4.1 Scenario1................................... 89 5.4.2 Scenario2................................... 89 5.4.3 Scenario3................................... 90 5.4.4 Scenario4................................... 91 5.5 Worked example: four scenarios . 91 v 5.5.1 Worked Example – Scenario 1 . 92 5.5.2 Worked Example – Scenario 2 . 96 5.5.3 Worked Example – Scenario 3 . 99 5.5.4 Worked Example – Scenario 4 . 103 5.5.5 Worked example - Summary of the four scenarios . 104 5.6 Summaryofthechapter ............................... 105 6 Automating and synchronising the missing data 106 6.1 Introduction...................................... 106 6.2 Background...................................... 108 6.2.1 VClog .................................... 108 6.2.2 BTdata ................................... 109 6.3 StructureofTheFramework............................. 110 6.3.1 VC Log Parser Via CVSAnalY . 112 6.3.2 BT data Parser Via Bicho . 112 6.4 Implementation.................................... 112 6.4.1 Retrieving VC Logs . 113 6.4.2 RetrievingBTData ............................. 113 6.4.3 Data Cleaning . 114 6.4.4 IsolatingTheBugIDs ............................ 114 6.4.5 Evaluation . 115 6.5 Quantification of VC logs and BT data . 116 6.6 Re-engineering Bicho and CVSAnalY . 119 6.7 Synchronisation.................................... 120 6.7.1 T1: Bicho – CVSAnalY . 120 6.7.2 T1: CVSAnalY – Bicho . 121 6.7.3 Issues with synchronisation . 123 6.8 Re-aligning CVSAnalY and Bicho . 124 6.8.1 T2Bicho–IssuesBichotable . 125 vi 6.8.2 T2: CVSAnalY – SCMlogCVSAnalY table . 125 6.8.3 Implementation of Auxiliary Tables . 125 6.9 Summaryofthechapter ............................... 132 7 Conclusion and Threats to Validity 133 7.1 Introduction...................................... 133 7.2 Contributionsofthisthesis ............................. 134 7.3 Beneficiaries and impact of this thesis . 135 7.4 Evaluation of the thesis contribution . 136 7.5 Threatstovalidity .................................. 139 7.5.1 Threats to validity (Chapter 3) . 139 7.5.1.1 Internal validity . 139 7.5.1.2 External validity . 141 7.5.2 Threats to validity (Chapter 4) . 141 7.5.2.1 Internal validity
Load more

Recommended publications
  • Defect Tracking System Project Documentation
    Defect Tracking System Project Documentation Tottering Barr azotise some Faust and gyps his surplices so sweetly! Northrup remains impellent after Sigfried havers nominally or fluorescing any good-byes. Remus orientalize thunderously? So much like automation and project defect tracking documentation but not win any kind of the organization tries to track the list by the beginning development team and let an. The amount of tracking system project defect tracking system! All comments are moderated before publication and desire meet our guidelines. Testing is a lousy part of mature software life cycle, and recent trends in software engineering evidence the importance all this activity all survey the development process. Diving deeper into program language theory is a great way data grow outside a developer. Your comment has been received. Bug reporting by the Web and email. Her homeland of interests are Wireless Networks and Database Management Systems. As projects grow in size and complexity, the limits of an Excel story for tracking issues begin to show which quickly. Thank who for using our services. Ten reports engine is a few lines of system project defect tracking documentation appears every single pane contains the. Defect tracking is responsible system authority is applied for any system software so run system performs well. User interface and learning curve the system user interfaces are more user friendly than others. Switch to fullscreen mode always show business bug attributes at once. Some custom structure for large body usually, evaluating and tracking system project defect documentation related documents, planning with your development organization efficiently and eliminate bad.
    [Show full text]
  • Tuto Documentation Release 0.1.0
    Tuto Documentation Release 0.1.0 DevOps people 2020-05-09 09H16 CONTENTS 1 Documentation news 3 1.1 Documentation news 2020........................................3 1.1.1 New features of sphinx.ext.autodoc (typing) in sphinx 2.4.0 (2020-02-09)..........3 1.1.2 Hypermodern Python Chapter 5: Documentation (2020-01-29) by https://twitter.com/cjolowicz/..................................3 1.2 Documentation news 2018........................................4 1.2.1 Pratical sphinx (2018-05-12, pycon2018)...........................4 1.2.2 Markdown Descriptions on PyPI (2018-03-16)........................4 1.2.3 Bringing interactive examples to MDN.............................5 1.3 Documentation news 2017........................................5 1.3.1 Autodoc-style extraction into Sphinx for your JS project...................5 1.4 Documentation news 2016........................................5 1.4.1 La documentation linux utilise sphinx.............................5 2 Documentation Advices 7 2.1 You are what you document (Monday, May 5, 2014)..........................8 2.2 Rédaction technique...........................................8 2.2.1 Libérez vos informations de leurs silos.............................8 2.2.2 Intégrer la documentation aux processus de développement..................8 2.3 13 Things People Hate about Your Open Source Docs.........................9 2.4 Beautiful docs.............................................. 10 2.5 Designing Great API Docs (11 Jan 2012)................................ 10 2.6 Docness.................................................
    [Show full text]
  • The Opendaylight Open Source Project
    UNIVERSIDAD REY JUAN CARLOS Master´ Universitario en Software Libre Curso Academico´ 2014/2015 Proyecto Fin de Master´ The OpenDaylight Open Source Project Autor: Sergio Najib Arroutbi Braojos Tutor: Dr. Gregorio Robles 2 Agradecimientos A mi familia y a mi pareja, por su apoyo incondicional Al equipo de Libresoft de la Universidad Rey Juan Carlos, por su afan´ en ensenar˜ el que´ y el porque´ del Software Libre Dedicatoria Para todos aquellos´ que hacen posible el fenomeno´ del Software Libre 4 (C) 2014 Sergio Najib Arroutbi Braojos. Some rights reserved. This document is distributed under the Creative Commons Attribution-ShareAlike 3.0 license, available in http://creativecommons.org/licenses/by-sa/3.0/ Source files for this document are available at http://github.com/sarroutbi/MFP/opendaylight/ 6 Contents 1 Introduction 19 1.1 Terminology.................................... 19 1.1.1 Open Source Programmable Networking................ 19 1.2 About this document............................... 20 1.2.1 Document structure............................ 20 1.2.2 Scope................................... 21 1.2.3 Methodology............................... 21 2 Goals and Objectives 23 2.1 General Objectives................................ 23 2.2 Subobjectives................................... 23 2.2.1 Acquire competence on OpenDaylight project.............. 23 2.2.2 Analyze OpenDaylight project from an Open Source perspective.... 24 2.2.3 Statistics and measures of the OpenDaylight project.......... 24 3 OpenDaylight: A first view 25 3.1 OpenDaylight Project............................... 25 3.2 SDN........................................ 29 3.2.1 What is SDN?.............................. 29 3.2.2 SDN: Market share and expectations................... 31 3.3 NFV........................................ 34 3.3.1 What is NFV?.............................. 35 3.3.2 SDN/NFV relationship.......................... 36 3.3.3 NFV benefits..............................
    [Show full text]
  • Atlassian Is Primed to Widen Its Appeal Beyond IT
    Seth Agulnick, [email protected] REPORT Atlassian Is Primed to Widen Its Appeal Beyond IT Companies: CA, CRM, GOOG/GOOGL, HPE, IBM, JIVE, MSFT, NOW, ORCL, TEAM, ZEN February 11, 2016 Report Type: Initial Coverage ☐ Previously Covered Full Report ☐ Update Report Research Question: Will Atlassian’s workflow tools continue to grow quickly with software development teams while also expanding into new use cases? Summary of Findings Silo Summaries . Atlassian Corp. Plc’s (TEAM) tracking and collaboration tools, widely 1) Atlassian Software Users considered the best-in-class for software development, are gaining JIRA and Confluence are both effective tools for team traction among nontechnical teams. collaboration. JIRA can be customized to suit nearly any team’s development process, though setup is . The company’s two flagship products, JIRA and Confluence, are complicated. Confluence is much easier to use and slowly being rolled out in departments like human resources, sales, tends to be deployed more widely. Atlassian’s biggest customer support and product management. These represent a advantage is the way all of its software pieces work together. Atlassian products—which already are being much larger market than Atlassian’s traditional core in IT. branched out beyond software development—can grow . JIRA was praised for its flexibility and advanced customization even further with business teams. options, though the latter trait makes setup and maintenance a challenge. It has great potential for sales growth with any business 2) Users of Competing Software Three of these five sources said Atlassian’s JIRA is not team that needs to track numerous tasks through a multistage the right fit for every company.
    [Show full text]
  • Letter, If Not the Spirit, of One Or the Other Definition
    Producing Open Source Software How to Run a Successful Free Software Project Karl Fogel Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel Copyright © 2005-2021 Karl Fogel, under the CreativeCommons Attribution-ShareAlike (4.0) license. Version: 2.3214 Home site: https://producingoss.com/ Dedication This book is dedicated to two dear friends without whom it would not have been possible: Karen Under- hill and Jim Blandy. i Table of Contents Preface ............................................................................................................................. vi Why Write This Book? ............................................................................................... vi Who Should Read This Book? ..................................................................................... vi Sources ................................................................................................................... vii Acknowledgements ................................................................................................... viii For the first edition (2005) ................................................................................ viii For the second edition (2021) .............................................................................. ix Disclaimer .............................................................................................................. xiii 1. Introduction ...................................................................................................................
    [Show full text]
  • Impact of Switching Bug Trackers: a Case Study on a Medium-Sized Open Source Project Théo Zimmermann, Annalí Casanueva Artís
    Impact of switching bug trackers: a case study on a medium-sized open source project Théo Zimmermann, Annalí Casanueva Artís To cite this version: Théo Zimmermann, Annalí Casanueva Artís. Impact of switching bug trackers: a case study on a medium-sized open source project. ICSME 2019 - International Conference on Software Maintenance and Evolution, Sep 2019, Cleveland, United States. hal-01951176v3 HAL Id: hal-01951176 https://hal.inria.fr/hal-01951176v3 Submitted on 26 Jul 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Impact of switching bug trackers: a case study on a medium-sized open source project Theo´ Zimmermann ([email protected]) Annal´ı Casanueva Art´ıs Universite´ de Paris, IRIF, CNRS, F-75013 Paris, France Paris School of Economics, F-75014 Paris, France Inria, π:r2 project-team Abstract—For most software projects, the bug tracker is an bugs fixed [6]. More generally, opening issues and discussing essential tool. In open source development, this tool plays an existing ones has been shown to be an important step on the even more central role as it is generally open to all users, who path to becoming an active contributor of an open source are encouraged to test the software and report bugs.
    [Show full text]
  • Latex in Twenty Four Hours
    Plan Introduction Fonts Format Listing Tabbing Table Figure Equation Bibliography Article Thesis Slide A Short Presentation on Dilip Datta Department of Mechanical Engineering, Tezpur University, Assam, India E-mail: [email protected] / datta [email protected] URL: www.tezu.ernet.in/dmech/people/ddatta.htm Dilip Datta A Short Presentation on LATEX in 24 Hours (1/76) Plan Introduction Fonts Format Listing Tabbing Table Figure Equation Bibliography Article Thesis Slide Presentation plan • Introduction to LATEX Dilip Datta A Short Presentation on LATEX in 24 Hours (2/76) Plan Introduction Fonts Format Listing Tabbing Table Figure Equation Bibliography Article Thesis Slide Presentation plan • Introduction to LATEX • Fonts selection Dilip Datta A Short Presentation on LATEX in 24 Hours (2/76) Plan Introduction Fonts Format Listing Tabbing Table Figure Equation Bibliography Article Thesis Slide Presentation plan • Introduction to LATEX • Fonts selection • Texts formatting Dilip Datta A Short Presentation on LATEX in 24 Hours (2/76) Plan Introduction Fonts Format Listing Tabbing Table Figure Equation Bibliography Article Thesis Slide Presentation plan • Introduction to LATEX • Fonts selection • Texts formatting • Listing items Dilip Datta A Short Presentation on LATEX in 24 Hours (2/76) Plan Introduction Fonts Format Listing Tabbing Table Figure Equation Bibliography Article Thesis Slide Presentation plan • Introduction to LATEX • Fonts selection • Texts formatting • Listing items • Tabbing items Dilip Datta A Short Presentation on LATEX
    [Show full text]
  • E-BUG TRACKING SYSTEM GUIDE: Mrs
    E-BUG TRACKING SYSTEM GUIDE: Mrs. Sathya Priya R1 R.B. Babu2, R. Marimuthu3, G. Gowtham4, V. Prakash5 1Assistant Professor, KSR Institute for Engineering and Technology, Tiruchengode. 2,3,4,5Department of Computer Science And Engineering, KSR Institute for Engineering and Technology, Tiruchengode. ABSTRACT This is the world of information. The ever-growing field Information Technology has its many advanced notable features which made it what it was now today. In this world, the information has to be processed, clearly distributed and must be efficiently reachable to the end users intended for that. Otherwise, we know it led to disastrous situations. The other coin of the same phase is it is absolutely necessary to know any bugs that are hither-to face by the end users. The project “e-bug tracking system” aims to provide the solution for that. The Bug Tracker can be made from any two types. The first one being the system side, the other being the services side. Our project deals with the second one. The paper is wholly dedicated to tracking the bugs that are hither- by arise. The administrator maintains the master details regarding to the bugs id, bugs type, bugs description, bugs severity, bugs status, user details. The administrator too has the authority to update the master details of severity level, status level, etc, modules of the paper. The administrator adds the users and assign them responsibility of completing the paper. Finally, on analysing the paper assigned to the particular user, the administrator can track the bugs, and it is automatically added to the tables containing the bugs, by order of severity and status.
    [Show full text]
  • Shop Documentation Release 0.0.1
    Shop Documentation Release 0.0.1 Fabian Affolter 04.07.2014 Inhaltsverzeichnis 1 Basics 3 1.1 Products.................................................3 1.2 Personas.................................................4 1.3 Use cases.................................................4 1.4 Design principles.............................................5 2 Web shop Design 7 2.1 General..................................................7 2.2 Layout..................................................7 2.3 Sitemap..................................................8 2.4 Main page................................................9 3 Style and design 11 3.1 Cascading Style Sheets.......................................... 11 3.2 Pages................................................... 11 4 Dynamics 13 4.1 Setup................................................... 13 4.2 Current year............................................... 13 4.3 Navigation Menu............................................. 13 4.4 List of Products.............................................. 14 4.5 Company details............................................. 15 5 External files 17 5.1 Navigation Menu............................................. 17 5.2 Header.................................................. 17 5.3 Footer................................................... 18 6 Input processing 19 6.1 “Buy Now” links............................................. 19 6.2 Select options............................................... 20 7 Javascript 21 7.1 Simple use case.............................................
    [Show full text]
  • Bug Tracker Net Documentation
    Bug Tracker Net Documentation Piscatorial and platelike Jean-Pierre backwash rigorously and immerge his pup pausingly and qualmishly. Glaucescent and nicotinic Sayers meditates anachronistically and reregulating his Bruges redolently and unemotionally. Jurassic Miguel befool whitely while Stevie always dedicating his squeezers marauds unthankfully, he miring so monumentally. The targeted project issue date. The predefined values should put left alone. Default user preference to enable filtering based on issue severity. Your comment has been received. Mantis Bug Tracker REST API Postman. It might been released, settings, you create and wade a script. NET Framework XML classes to steep and manipulate the data assess them. Compare to other products or configurations, take their moment to browse these introductory docs. Try upgrading to the latest stable version. The consider of filter fields to buy per row. We erect not, schedules, an object will be flagged. Alternatively, hence, we to submit a report back soon please report cannot be displayed on to main window. Automate data source between Sheets and Tracker. NET, remainder of the bugs are readable, their description etc in the cemetery of reports from time start time. It will no longer if possible login using this account. Then what problem behavior be solved more promptly. Someone hijacked my Google account. Kanban board for visualizing your project timeline. Default value list ON. The default value somewhere ON. Google users are affected. Specifies the LDAP or Active Directory server to key to. You can afford click the Updated column heading to which most recently updated issues at our top along the search results.
    [Show full text]
  • Introduction to LATEX Word
    LaTeX.1 Introduction to LATEX The files used in this section are first.tex, first.pdf, RJournal.zip, Biometrics.zip, and nuthesis.zip. Word Word is a word processor. It is based on the “what you see is what you get” (WYSIWYG) philosophy of typing documents. The soft- ware allows one to see immediately what the document is going to look like printed after it is typed. I really like Word. Through typing a 300+ page dissertation in Word, lecture notes for most courses, and many published journal articles, I have learned how to use Word very well. However, there are issues with the software: • Current Word equation editor: It simply is not good enough for complex equations. MathType serves as very nice replace- ment, but there are some issues with its use (to be discussed shortly). • Floating tables and figures: While you can do these (anchor a table or figure to a page), I often have problems getting text to flow around it. • Euclid font: MathType’s Euclid font allows for a Word docu- ment to look similar to that of the default Computer Modern font of LATEX. However, Greek letters and symbols often look a little different in and outside of equations. • In-line equations: You need to manually break equations at the end of a line. This is especially needed with full justifica- tion of text. • Equation sizing: MathType equations are embedded images. The sizes of these images change over many saves of a Word LaTeX.2 document (since Word 2007). • 64-bit capability:There has been issues with 64-bit Word com- patibility of MathType (I have not checked this with the newest version of MathType).
    [Show full text]
  • Modern Open Source Java EE-Based Process and Issue Tracker
    MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS Modern open source Java EE-based process and issue tracker DIPLOMA THESIS Monika Gottvaldová Brno, 2014 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Monika Gottvaldová Advisor: doc. RNDr. Tomáš Pitner, Ph.D. ii Acknowledgement I would like to thank Ing. OndˇrejŽižka for his advice and help during the creation of this thesis. iii Abstract This thesis deals with the topic concerning issue tracking systems, their functionality and features. It compares several issue tracking systems, their advantages and disadvantages. It describes a development of such a sys- tem and the use of modern Java EE technologies – JPA, Wicket, and CDI. The main motivation for creating a new issue tracking system and the sub- sequent development is also described. The thesis analyses its basic design and implementation. iv Keywords Issue tracking system, Wicket, modern Java EE, issue, bug, workflow, cus- tomization v Contents 1 Introduction ...............................1 2 Issue Tracking Systems ........................3 2.1 Bugzilla . .4 2.2 Trac . .6 2.3 JIRA . .7 2.4 Mantis . .8 2.5 BugTracker.NET . .9 2.6 Redmine . 10 2.7 FogBugz . 11 3 Analysis of Relevant Processes in Red Hat ............. 14 3.1 RHEL 6 QE . 14 3.1.1 Process Phases Description . 14 3.1.2 Bugzilla Process . 15 3.2 Fedora QE . 16 3.2.1 Process Phases Description .
    [Show full text]