ICSM 2013 MIPPopulating a Release History DB

Michael Fischer Martin Pinzger Harald C. Gall

University of Zurich, SwitzerlandUniversity of Klagenfurt, Austria

Roadmap

Back to 2003Impact of the WorkMining Software RepositoriesFrom RHDB to recent research

2

Motivation back in 2003

Version control and bug tracking systems need to be integratedlarge amounts of historical information can give insights

but provide only insufficient support for a detailed analysis of software evolution

Our goal was to populate a Release History Database that combines version data with bug tracking data and adds missing information not covered by version control systems such as merge points or bug links.

to enable systematic queries to the structured data to obtain meaningful views showing the evolution of a software project.

to enable more accurate reasoning of evolutionary aspects.

3

Populating a Release History DB

Problem = re-establishment of links between modification reports (MRs) and problem reports (PRs) since no mechanisms are provided by CVSWe use PR IDs found in the MRs of CVSPR IDs in MRs are detected using a set of regular expressions. A match is rated according to the confidence value: high (h), medium (m), or low (l)

confidence is considered high if expressions such as <keyword><ID> can be detected confidence is considered low a six digit number just appearing somewhere in the text of a modification report without preceding keyword

4

Building a Release History DB

3 main sources:Modification reports (MR): CVSProblem reports (PR): Bugzilla

program and patch information: Release Packages

Relevant MRs and PRs are filtered, validated and stored in a Release History DB (RHDB)

5

Import process

6

RHDB schema (meta-model)

7

Views on Mozilla evolution

50% of files have been modified in last quarter of observationalthough only 25% of files have been integrated

8

Views on Mozilla evolution /2

modules

size

9

Feature evolution

10

Conclusions from 2003

RHDB offers some benefits for evolution analysisqualified links between changes and bugsfiles logically coupled via changes and bugs

branch/merge revision data

Data set as a basis for further analyses and visualizations (e.g. MDS-view)

A basis for data exchange among research groups in the direction of a meta-model for release data

11

Next steps: outlook from 2003

Further revise and develop meta-model for release data exchangeProvide a qualified set of queries to the RHDBIntegrate with other evolution analyses and evolution data in a framework

bug report datamodification report datatest data and properties

feature informationmulti-dimensional visualization

12

Impact of RHDB work

Google Scholar: 387

with MSR 2004 in Edinburgh, 2005 in St. Louis

Citations

14

Paper titles (top 16)

15

Conferences

16

Paper authors (top 100)

17

What is referenced?

...Also, numerical bug IDs mentioned in the commit log, are linked back to the issue tracking system’s identifiers [21, 44]... (F. Rahman, et al.)

...First, we searched for keywords such as “bug”, “bugs”, “bug fixes”, and “fixed bug”, or references to bug IDs in log files; ... [39, 15, 29]... (P. Bhattacharya et al.)

..While modern systems like Subclipse (http://subclipse.tigris.org) allow to link bug reports and code modifications, most of the time these links are not available [12]... (W. Poncin, et al.)

18

From RHDB to Mining Software Repositories

Mining Software Repositories

Does distributed development affect software quality?Cross-project defect prediction: when does it work?

Visual (Effort Estimation) Patterns in Issue Tracking DataVisual Understanding of Source Code Dependencies

Analyzing the co-evolution of comments and codePredicting the fix time of bugsSupporting developers with Natural Language QueriesCan Developer-Module Networks Predict Failures?Interactive Views for Analyzing Problem Reports

20

From RHDB to Change Type Analysis: Change Distiller

Beat Fluri and Harald Gall

Source Code Changes using ASTs

Using tree differencing, we can determine

public void method(D d) {if (d != null) {

d.foo();d.bar();

}}

public void method(D d) {d.foo();d.bar();

}

22

Using tree differencing, we can determineenclosing entity (root node)

Source Code Changes using ASTs

public void method(D d) {if (d != null) {

d.foo();d.bar();

}}

public void method(D d) {d.foo();d.bar();

}

23

Using tree differencing, we can determineenclosing entity (root node)kind of statement which changed (node information)

kind of change (tree edit operation)

Source Code Changes using ASTs

public void method(D d) {d.foo();d.bar();

}

24

public void method(D d) {if (d != null) {

d.foo();d.bar();

}}

Using tree differencing, we can determineenclosing entity (root node)kind of statement which changed (node information)

kind of change (tree edit operation)

Source Code Changes using ASTs

public void method(D d) {if (d != null) {

d.foo();d.bar();

}}

public void method(D d) {d.foo();d.bar();

}

25

ChangeDistiller Model

uniqueNameshortNametype

SourceCodeEntitystructureEntitysourceCodeEntitytype

ChangeOperation

parentEntityInsert

parentEntityDelete

oldParentEntitynewParentEntity

MovenewEntityparentEntity

Update

uniqueNametypebodyChangesdeclarationChanges

StructureEntity

*

changeTypechangeOperations

SourceCodeChange*

structureEntityversion

StructureEntityVersion

attributeVersionsAttributeHistory

methodVersionsMethodHistory

*classVersionsattributeHistoriesinnerClassHistoriesmethodHistories

ClassHistory

*

*

*

Revision

link to

org.evolizer.model.versioning

BodyChange

DeclarationChange*

*

26

ChangeDistiller

De

27https://bitbucket.org/sealuzh/tools-changedistiller/wiki/Home

From RHDB to Software Analysis as a Service (SOFAS)

Giacomo Ghezzi and Harald Gall

SOFtware Analysis Services

The actual repository analysis is offered as a serviceThe user selects the analysis with the data to be analyzed and gets the results (workflow)Data is key; analyses can be lengthy and expensive!

29

SOFAS scenario

SVN HistoryService

OOMetricsService

FamicModel

Service

30

GeneralConcepts

Domain Specific Concepts

System Specific Concepts

Bugs Code History

CVS SVN GITJava C#Bugzilla Trac

Issue Tracking

Bugzilla TracChange Coupling

Change Types

Source Code

C#Java Software Design Metrics

Version Control

CVS SVN GIT

SEON Pyramid(s)www.se-on.org

31

Semantic Links

http://myProject.org/bugs/nr124

Bug History extractor

http://ifi.uzh.ch/svnImportermyProject/Foo.java23

Version Controlhistory extractor

Bug-Revision linker

http://myProject.org/bugs/nr124http://sofas.org/bugOntology/affectshttp://ifi.uzh.ch/svnImporter/myProject/Foo.java23

Current SOFAS services

Data GatherersVersion history extractor for CVS, SVN, GIT, and MercurialIssue tracking history for Bugzilla, Trac, SourceForge, Jira

Basic ServicesMeta-model extractors for Java and C# (FAMIX)Change coupling, change typesIssue-revision linkerMetrics service

Composite servicesEvolutionary hot-spotsHighly changing Code Clonesand many more ...

33

Software Analysis Workflows

34

35

Software Facets - a glimpse

From RHDB to Defect Prediction

Emanuel Giger, Martin Pinzger, and Harald Gall

RHDB for Defect Prediction

Some of our defect prediction papersPredicting defect densities in source code files with decision tree learners (MSR 2006)Improving defect prediction using temporal features and non linear models (IWPSE 2007)

Predicting the fix time of bugs (RSSE 2010)Comparing fine-grained source code changes and code churn for bug prediction (MSR 2011)Method-Level Bug Prediction (ESEM 2012)

37

Prediction granularity

11 methods on average

class 1 class 2 class 3 class n...class 2

4 are bug prone (ca. 36%)

Goal: Prediction model to identify bug-prone methods 38

Large files are typically the most bug-prone files

Approach for defect prediction

study with the Eclipse projects. We discuss our findings inSection 4 and threats to validity in Section 5. In Section 6,we present related work and then draw our conclusions inSection 7.

2. APPROACHIn this section, we describe the methods and tools we used

to extract and preprocess the data (see Figure 1). Basically,we take into account three main pieces of information aboutthe history of a software system to assemble the dataset forour experiments: (1) versioning data including lines modi-fied (LM), (2) bug data, i.e., which files contained bugs andhow many of them (Bugs), and (3) fine-grained source codechanges (SCC).

4. Experiment

2. Bug Data

3. Source Code Changes (SCC)1.Versioning Data

CVS, SVN,GIT

Evolizer RHDB

Log Entries ChangeDistiller

SubsequentVersions

Changes

#bug123

Message Bug

SupportVector

Machine

1.1 1.2

ASTComparison

Figure 1: Stepwise overview of the data extraction process.

1. Versioning Data. We use EVOLIZER [14] to access the ver-sioning repositories , e.g., CVS, SVN, or GIT. They providelog entries that contain information about revisions of filesthat belong to a system. From the log entries we extract therevision number (to identify the revisions of a file in correcttemporal order), the revision timestamp, the name of the de-veloper who checked-in the new revision, and the commitmessage. We then compute LM for a source file as the sum oflines added, lines deleted, and lines changed per file revision.2. Bug Data. Bug reports are stored in bug repositories suchas Bugzilla. Traditional bug tracking and versioning repos-itories are not directly linked. We first establish these linksby searching references to reports within commit messages,e.g.,”fix for 12023” or ”bug#23467”. Prior work used thismethod and developed advanced matching patterns to catchthose references [10, 33, 39]. Again, we use EVOLIZER to au-tomate this process. We take into account all references tobug reports. Based on the links we then count the number ofbugs (Bugs) per file revision.3. Fine-Grained Source Code Changes (SCC): Current ver-sioning systems record changes solely on file level and tex-tual basis, i.e., source files are treated as pure text files. In [11],Fluri et al. showed that LM recorded by versioning systemsmight not accurately reflect changes in the source code. Forinstance, source formatting or license header updates gen-erate additional LM although no source code entities werechanged; changing the name of a local variable and a methodlikely result both in ”1 line changed” but are different modi-fications. Fluri et al. developed a tree differencing algorithmfor fine-grained source code change extraction [13]. It allowsto track fine-grained source changes down to the level of

Table 1: Eclipse dataset used in this study.Eclipse Project Files Rev. LM SCC Bugs TimeCompare 278 3’736 140’784 21’137 665 May01-Sep10jFace 541 6’603 321582 25’314 1’591 Sep02-Sep10JDT Debug 713 8’252 218’982 32’872 1’019 May01-July10Resource 449 7’932 315’752 33’019 1’156 May01-Sep10Runtime 391 5’585 243’863 30’554 844 May01-Jun10Team Core 486 3’783 101’913 8’083 492 Nov01-Aug10CVS Core 381 6’847 213’401 29’032 901 Nov01-Aug10Debug Core 336 3’709 85’943 14’079 596 May01-Sep10jFace Text 430 5’570 116’534 25’397 856 Sep02-Oct10Update Core 595 8’496 251’434 36’151 532 Oct01-Jun10Debug UI 1’954 18’862 444’061 81’836 3’120 May01-Oct10JDT Debug UI 775 8’663 168’598 45’645 2’002 Nov01-Sep10Help 598 3’658 66’743 12’170 243 May01-May10JDT Core 1’705 63’038 2’814K 451’483 6’033 Jun01-Sep10OSGI 748 9’866 335’253 56’238 1’411 Nov03-Oct10

single source code statements, e.g., method invocation state-ments, between two versions of a program by comparingtheir respective abstract syntax trees (AST). Each change thenrepresents a tree edit operation that is required to transformone version of the AST into the other. The algorithm is imple-mented in CHANGEDISTILLER [14] that pairwise comparesthe ASTs between all direct subsequent revisions of each file.Based on this information, we then count the number of dif-ferent source code changes (SCC) per file revision.

The preprocessed data from step 1-3 is stored into the Re-lease History Database (RHDB) [10]. From that data, we thencompute LM, SCC, and Bugs for each source file by aggregat-ing the values over the given observation period.

3. EMPIRICAL STUDYIn this section, we present the empirical study that we per-

formed to investigate the hypotheses stated in Section 1. Wediscuss the dataset, the statistical methods and machine learn-ing algorithms we used, and report on the results and find-ings of the experiments.

3.1 Dataset and Data PreparationWe performed our experiments on 15 plugins of the Eclipse

platform. Eclipse is a popular open source system that hasbeen studied extensively before [4, 27, 38, 39].

Table 1 gives an overview of the Eclipse dataset used inthis study with the number of unique *.java files (Files), thetotal number of java file revisions (Rev.), the total number oflines added, deleted, and changed (LM), the total number offine-grained source code changes (SCC), and the total num-ber of bugs (Bugs) within the given time period (Time). Onlysource code files, i.e., *.java, are considered.

After the data preparation step, we performed an initialanalysis of the extracted SCC. This analysis showed that thereare large differences of change type frequencies, which mightinfluence the results of our empirical study. For instance, thechange types Parent Class Delete, i.e., removing a super classfrom a class declaration, or Removing Method Overridability,i.e., adding the java keyword final to a method declaration,are relatively rare change types. They constitute less than onethousandth of all SCC in the entire study corpus. Whereasone fourth of all SCC are Statement Insert changes, e.g., the in-sertion of a new local variable declaration. We therefore ag-gregate SCC according to their change type semantics into 7categories of SCC for our further analysis. Table 2 shows theresulting aggregated categories and their respective mean-ings.

39

21 Java open source projects

40

Project #Classes #Methods #M-Histories #Bugs

JDT Core 1140 17703 43134 4888

Jena2 897 8340 7764 704

Lucene 477 3870 1754 377

Xerces 693 8189 6866 1017

Derby Engine 1394 18693 9507 1663

Ant Core 827 8698 17993 1900

Models computed with change metrics (CM) perform better than with source-code metrics (SCM)

authors and methodHistories are the most important measures

Results: Product and process metrics

41

Table 4: Median classification results over all pro-jects per classifier and per model

CM SCM CM&SCM

AUC P R AUC P R AUC P R

RndFor .95 .84 .88 .72 .5 .64 .95 .85 .95

SVM .96 .83 .86 .7 .48 .63 .95 .8 .96

BN .96 .82 .86 .73 .46 .73 .96 .81 .96

J48 .95 .84 .82 .69 .56 .58 .91 .83 .89

values of the code metrics model are approximately 0.7 foreach classifier—what is defined by Lessman et al. as ”promis-ing” [26]. However, the source code metrics su!er from con-siderably low precision values. The highest median precisionvalue for the code metrics model is obtained in case of J48(0.56). For the remaining classifiers the values are around 0.5.In other words, using the code metrics half of the methodsare correctly classified (the other half being false positives).Moreover, code metrics only achieve moderate median recallvalues close to 0.6 (except for NB), i.e., only two third of allbug-prone methods are retrieved.Second, the change metrics and the combined model per-

form almost equally. Moreover, both exhibit good values incase of all three performance measures (refers to RQ1 intro-duced in Section 1). Only the median recall values obtainedby SVM and BN for the combined model are significantlyhigher than the ones of the change metrics model (0.96 vs.0.86 in both cases). Moreover, while AUC and precision arefairly similar for these two models, recall seems to benefit themost from using both metric sets in combination comparedto change metrics only.Summarizing, we can say that change metrics significantly

outperform code metrics when discriminating between bug-prone and not bug-prone methods (refers to RQ2). A lookat the J48 tree models of the combined metrics set supportsthis fact as the code metrics are added towards the leaves ofthe tree, whereas except for three projects (˜14%) authorsis selected as root attribute. methodHistories is for 11 pro-jects (˜52%) the second attribute and in one case the root.Furthermore, considering the average prior probabilities inthe dataset (i.e., ˜32% of all methods are bug-prone), changemetrics perform significantly better than chance. Hence, theresults of our study confirms existing observations that his-torical change measures are good bug predictors, e.g., [17,30, 20, 24]. When using a combined model we might ex-pect slightly better recall values. However, from a strictstatistical point of view it is not necessary to collect codemeasures in addition to change metrics when predicting bug-prone methods.Regarding the four classifiers, our results are mostly con-

sistent. In particular, the performance di!erences betweenthe classifiers when based on the change and the combinedmodel are negligible. The largest variance in performanceamong the classifiers resulted from using the code metricsfor model building. However, in this case these results arenot conclusive: On the one hand, BN achieved significantlylower precision (median of 0.46) than the other classifiers.On the other hand, BN showed a significantly higher recallvalue (median of 0.73).

3.3 Prediction with Different Labeling PointsSo far we used the absence and presence of bugs to label a

method as not bug-prone or bug-prone, respectively. Approx-imately one third of all methods are labeled as bug-prone inour dataset (see Section 3.1). Given this number a developerwould need to spend a significant amount of her time for cor-rective maintenance activities when investigating all meth-ods being predicted as bug-prone. We analyze in this section,how the classification performance varies (RQ3) as the num-ber of samples in the target class shrinks, and whether weobserve similar findings as in Section 3.2 regarding the re-sults of the change and code metrics (RQ2). For that, weapplied three additional cut-point values as follows:

bugClass =

!

not bug ! prone : #bugs <= pbug ! prone : #bugs > p

(2)

where p represents either the value of the 75%, 90%, or 95%percentile of the distribution of the number of bugs in meth-ods per project. For example, using the 95% percentile ascut-point for prior binning would mean to predict the ”top-five percent” methods in terms of the number of bugs.

To conduct this study we applied the same experimentalsetup as in Section 3.1, except for the di!erently chosen cut-points. We limited the set of machine learning algorithms toone algorithm as we could not observe any major di!erencein the previous experiment among them (see Table 4). Wechose Random Forest (RndFor) for this experiment since itsperformance lied approximately in the middle of all classi-fiers.

Table 5 shows the median classification results over allprojects based on the RndFor classifier per cut-point andper metric set model. The cell coloring has the same inter-pretation as in Table 4: Grey shaded cells are significantlydi!erent from the white cells of the same performance mea-sure in the same row (i.e., percentile). For better readabilityand comparability, the first row of Table 5 (denoted by GT0,i.e., greater than 0, see Equation 1) corresponds to the firstrow of Table 4 (i.e., performance vector of RndFor).

We can see that the relative performances between themetric sets behave similarly to what was observed in Sec-tion 3.2. The change (CM) and the combined (CM&SCM)models outperform the source code metrics (SCM) model sig-nificantly across all thresholds and performance measures.The combined model, however, does not achieve a signifi-cantly di!erent performance compared to the change model.While the results in Section 3.2 showed an increase regard-ing recall in favor of the combined model, one can noticean improved precision by 0.06 in case of the 90% and the95% percentile between the change and combined model—although not statistically significant. In case of the 75% per-centile the change and the combined model achieve nearlyequal classification performance.

Comparing the classification results across the four cut-points we can see that the AUC values remain fairly constanton a high level for the change metrics and the combinedmodel. Hence, the choice of a di!erent binning cut-pointdoes not a!ect the AUC values for these models. In contrast,a greater variance of the AUC values is obtained in the caseof the classification models based on the code metric set.For instance, the median AUC value when using GT0 forbinning (0.72) is significantly lower than the median AUCvalues of all other percentiles.

Generally, precision decreases as the number of samplesin the target class becomes smaller (i.e., the higher the per-centile). For instance, the code model exhibits low preci-

Lessons from Defect Prediction

Bug predictions do workCross-project predictions do not really work Data sets (systems) as benchmarkData preprocessing and learners need to be calibratedStudies need to be replicable (systematically)

42

From RHDB to Evolution of Service-oriented Systems

Daniele Romano and Martin Pinzger

Fine-Grained Changes for WSDLs

44

III. WSDLDIFF

In this section, we illustrate the WSDLDiff tool used toextract the fine-grained changes between two versions ofa WSDL interface. Since the tool is based on the EclipseModeling Framework, we first present an overview of thisframework and then we describe the fine-grained changesextraction process implemented by WSDLDiff. A first pro-totype of WSDLDiff is available on our web site.7

A. Eclipse Modeling FrameworkThe Eclipse Modeling Framework (EMF) is a modeling

framework that lets developers build tools and other appli-cations based on a structured data model. This frameworkprovides tools to produce a set of Java classes from a modelspecification and a set of adapter classes that enable viewingand editing of the models. The models are described by metamodels called Ecore.

As part of the EMF project, there is the EMF Compareplug-in. It provides comparison and merge facilities for anykind of EMF Models through a framework easy to be usedand extended to compare instances of EMF Models. TheEclipse community provides already an Ecore meta modelfor WSDL interfaces, including a meta model for XSD, andtools to parse them into EMF Models. We use these featuresto parse and extract changes between WSDL interfaces asdescribed in the following.

B. Fine-Grained Changes Extraction ProcessFigure 1 shows the process implemented by WSDLDiff

to extract fine-grained changes between two versions of aWSDL interface. The process consists of four stages:

• Stage A: in the first stage we parse the WSDLinterfaces using the APIs provided by theorg.eclipse.wst.wsdl and org.eclipse.xsd projects. Theoutput of this stage consists of the two EMF Models(WSDL Model1 and WSDL Model2) correspondingto the two WSDL interfaces taken as input (WSDLVersion1 and WSDL Version2).

• Stage B: in this stage we transform the EMF Modelscorresponding to the XSD (contained by the WSDLmodels) in order to improve the accuracy of the fine-grained changes extraction process as it will be shownin the Subsection III-D. The output of this stage consistof the transformed models (WSDL Model1’ and WSDLModel2’).

• Stage C: in the third stage we use the Matching Engineprovided by the EMF Compare framework to detect thenodes that match in the two models.

• Stage D: the Match Model produced by the MatchingEngine is then used to detect the differences amongthe two WSDL models under analysis. This task is

7http://swerl.tudelft.nl/twiki/pub/DanieleRomano/WebHome/WSDLDiff.zip

Matching)Engine)org.eclipse.compare.match/

Match/Model/

Diff/Model/

Differencing)Engine)org.eclipse.compare.diff/

XSD)Transformer) XSD)Transformer)

WSDL/Model1’/ WSDL/Model2’/

WSDL/Model1/ WSDL/Model2/

WSDL/Version1/ WSDL/Version2/

WSDL)Parser)org.eclipse.wst.wsdl/

org.eclipse.xsd/

WSDL)Parser)org.eclipse.wst.wsdl/

org.eclipse.xsd/A

B)

C)

D

Figure 1: The process implemented by WSDLDiff to extractfine-grained changes between two versions of a WSDLinterface.

accomplished by the Differencing Engine provided alsoby EMF Compare. The output of this stage is a tree ofstructural changes that reports the differences betweenthe two WSDL models. The differences are reported interms of additions, removals, moves and modificationsof each element specified in the WSDL and in the XSD.

In the next subsection we first illustrate the strategiesbehind EMF Compare describing the matching (Stage C)and differencing (Stage D) stages and then we describe theXSD transformation (Stage B).

C. Eclipse EMF Compare

The comparison facility provided by EMF Compare isbased on the work developed by Xing et al. [19]. Thiswork has been adapted to compare generic EMF Modelsinstead of UML models as initially developed by Xing. Thecomparison consists of two phases: (1) the matching phase(Stage C in our approach) and (2) the differencing phase(Stage D in our approach). The matching phase is performedcomputing a set of similarity metrics. These metrics arecomputed for two nodes while traversing the two modelsunder analysis with a top-down approach. In the genericMatching Engine, provided in org.eclipse.compare.matchand used in our approach, the set of metrics consists of foursimilarity metrics:

• type similarity: to compute the match of the types oftwo nodes;

• name similarity: to compute the similarity between thevalues of the attribute name of two nodes;

Changes in WSDLs

45

Change Type AmazonEC2 FedEx Rate FedEx Ship FedEx PkgOperationA 113 1 10 0OperationC 0 1 0 0OperationD 9 1 4 0MessageA 218 2 16 0MessageC 2 0 2 0MessageD 10 2 2 0PartA 27 0 2 0PartC 34 0 0 0PartD 27 0 2 0Total 440 7 38 0

Operations and messages are added but rarely deleted

Changes in Data Types

46

Change Type AmazonEC2 FedEx Rate FedEx Ship FedEx PkgXSDTypeA 409 234 157 0XSDTypeC 160 295 280 6XSDTypeD 2 71 28 0

XSDElementA 208 2 25 0XSDElementC 1 0 18 0XSDElementD 0 2 0 0

XSDAttributeGroupA 6 0 0 0XSDAttributeGroupC 5 0 0 0

Total 791 604 508 6

Data types are added but rarely deleted

What we learned from WSDL evolution

47

Users of the FedEx serviceData types change frequentlyOperations are more stable

Users of the AmazonEC2 serviceNew operations are continuously addedData types change frequently adding new elements

Analyzing the Evolution of Web Services using Fine-Grained Changes D. Romano and M. Pinzger, ICWS 2012

What is next?

48

What is next?

RHDB

Evolizer, ChangeDistiller, SOFAS

DA4Java

Empirical studies on quality, change and defect prediction

year2003 2005 2007 2009 2011 2013

Spreadsheet analysis

ArchView

Web 2.0 for understanding

Service quality Ecosystem Evolution

Stakeholders Needs & Views

Replication Studies

Social Coding & Mining

Conclusions

50

Contactgall@ifi.uzh.ch

martin.pinzger@aau.at4. Experiment

2. Bug Data

3. Source Code Changes (SCC)1.Versioning Data

CVS, SVN,GIT

Evolizer RHDB

Log Entries ChangeDistiller

SubsequentVersions

Changes

#bug123

Message Bug

SupportVector

Machine

1.1 1.2

ASTComparison

Ecosystem Evolution

Stakeholders Needs & Views

Replication Studies

Social Coding & Mining