Populating a Release History Database from Version
Control and Bug Triaging System
 Michael Fischer, Martin Pinzger, and Harald Gall
 Distributed Systems Group, Vienna University of

Technology
 ffische...
Presented By:
 Muhammad Wahaj Farooqui
 Muhammad Arsalan
 Asad Ullah Khan
 Aftab Ahmed
:
Abstract View:
Version
Control/ Bug
Tracking

problems

Historical
information

Insufficient
support
Evolution of
Softwa...
INTRODUCTUION:

• In lifetime of software an amount of historical information is collected and
stored by Version Control S...
This paper is organizes as follows:
• Section II give overview of related work in area of software evolution analysis
• Se...
2. Related work
 As our knowledge is not enough in combining version

control and bug tracking for software evolution ana...
3. Overview of CVS and Bugzilla
 3.1 CVS:
 Basically, CVS is designed to handle revisions of textual

information by sto...
 3.2 Bugzilla:
 As additional source of information to the modification

reports, bug report data from the Bugzilla bug ...
 To overcome this limitation, we developed an algorithm

which delivers criteria for the acceptance or rejection of the
h...
5. Populating a Release history
Database
 Based on the data formats and structures used by CVS we

designed the Release H...
6. Import Process
 For the import of CVS and Bugzilla data into our RHDB we use a

straight forward process that basicall...
4. Bug report identifiers are extracted from the modification
reports contained in the CVS log files
5. The bug report IDs...
 Release history: Based on the time scale we can
compute the release history for all artifacts' in the RHDB.

 Coupling:...
8. Conclusion and Future Work
 In this paper, the information can be reconstructed but a

more formal mechanism supported...
Acknowledgment
 We thank the Mozilla developers for providing all
their data for this case study to analyze the
evolution...
Software Maintenance Bug Triaging
Software Maintenance Bug Triaging
Upcoming SlideShare
Loading in …5
×

Software Maintenance Bug Triaging

720 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
720
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Software Maintenance Bug Triaging

  1. 1. Populating a Release History Database from Version Control and Bug Triaging System
  2. 2.  Michael Fischer, Martin Pinzger, and Harald Gall  Distributed Systems Group, Vienna University of Technology  ffischer,pinzger,gallg@infosys.tuwien.ac.at
  3. 3. Presented By:  Muhammad Wahaj Farooqui  Muhammad Arsalan  Asad Ullah Khan  Aftab Ahmed
  4. 4. : Abstract View: Version Control/ Bug Tracking problems Historical information Insufficient support Evolution of Software Project combin e New approaches Apply queries Version Control/bug Tracking Demonstrate approach obtain Software Project Evolution Aspects offers Mozilla Open source Structured Data opportunities Comparison of Results
  5. 5. INTRODUCTUION: • In lifetime of software an amount of historical information is collected and stored by Version Control System. • This information tells different type of evolutionary aspects of project. • Information of version may be enhanced with data from bug tracking system which report against past maintenance activities. • In this paper we introduce the population of a Release History Database that combines version and bug report data and we further demonstrate some query examples with respect to software evolution analysis. • We demonstrate our approach on the Open Source project Mozilla that uses CVS as version control system and Bugzilla. • The Mozilla project also has been addressed by other approaches in the software evolution area.
  6. 6. This paper is organizes as follows: • Section II give overview of related work in area of software evolution analysis • Section III tells overview of CVS and Bugzilla • Section IV discuss problems of combined detection for Development branches • Section V will discuss data model • Section VI explain import process • Section VII evolution of Release history database Section VIII Conclusion and discussion of Future work
  7. 7. 2. Related work  As our knowledge is not enough in combining version control and bug tracking for software evolution analysis, so work focus on software evolution aspects and visualization  The focus of work is on deducing mappings of the systems life cycle (new program, corrective, adaptive, etc.)  The work also focused on the visualization of statistical data derived from the version control system  Since the release data were stored in an object oriented database this approach could not be reused for the investigation of other software systems using different version control systems.
  8. 8. 3. Overview of CVS and Bugzilla  3.1 CVS:  Basically, CVS is designed to handle revisions of textual information by storing subsequent revisions in the repository.  Revision Numbers:  Version control systems distinguish between version numbers of files and software products. Concerning files these numbers are called revision numbers and indicate different versions of a file. In terms of software products they are called release numbers  Version Control Data:  For each working file in the repository CVS generates version control data and stores it to log files. From there, log file information can be retrieved by issuing the cvs log command.
  9. 9.  3.2 Bugzilla:  As additional source of information to the modification reports, bug report data from the Bugzilla bug report database is imported into our Release History Database. Access to the Bugzilla database is enabled via HTTP and reports can be retrieved in XML format 4. Tracing Evolution Across Branches:  For the evolutionary analysis of Software Product Lines it is desirable to trace back the introduction of new code.  In CVS merges are performed on a pure textual level and can be performed automatically only if no conflicting situation during the merge operation occurs.
  10. 10.  To overcome this limitation, we developed an algorithm which delivers criteria for the acceptance or rejection of the hypothesis  Branch/merge algorithm: The algorithm is based on the observation that merges are performed either automatically through CVS and lines are copied into the main trunk or done by hand also by copying the source lines from the branch into the main trunk.
  11. 11. 5. Populating a Release history Database  Based on the data formats and structures used by CVS we designed the Release History Database (RHDB) that stores the extracted version and bug report data.  To improve the communication with our RHDB and also to increase efficiency we developed a query framework implemented in Java.
  12. 12. 6. Import Process  For the import of CVS and Bugzilla data into our RHDB we use a straight forward process that basically is driven by CVS and Bugzilla systems but also may be adapted to other such systems.  The data import process as depicted consists of the following steps: 1. The initial source code tree is created by either downloading the Mozilla source code packages or by checking out the source code directly from the Mozilla CVS repository. 2. Retrieval of log information 3. Every item of the source tree is described by the corresponding log information
  13. 13. 4. Bug report identifiers are extracted from the modification reports contained in the CVS log files 5. The bug report IDs are used to retrieve bug report descriptions from the Bugzilla database via HTTP. 7. Evaluation: .  In this section we evaluate our approach according to import, timescale, historical, and coupling aspects of Mozilla  Timescale: For the analysis of evolutionary aspects, e.g., system growth or change rate, it is necessary to create a time scale based on an appropriate granularity
  14. 14.  Release history: Based on the time scale we can compute the release history for all artifacts' in the RHDB.  Coupling: Another aspect of a large software system is that bug reports may not be seen in isolation and thought of a problem concerning a single file.
  15. 15. 8. Conclusion and Future Work  In this paper, the information can be reconstructed but a more formal mechanism supported by the version control system would be desirable  We can have overcome this problem by parsing the informal information contained in modification reports and linking them with data from the bug tracking system  A reduction of large amount of collected historical data and visualization of this condensate is crucial for understanding of the evolutionary processes in large software projects.
  16. 16. Acknowledgment  We thank the Mozilla developers for providing all their data for this case study to analyze the evolution of an Open Source project. Further, we thank the anonymous reviewers for their valuable comments.

×