Why do software packages conflict?

Artho, Cyrille; Suzaki, Kuniyasu; Cosmo, Roberto Di; Treinen, Ralf; Zacchiroli, Stefano

doi:10.1109/msr.2012.6224274

Cited by 38 publications

(27 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Thus, the number of changes in a feature may be a good indicator of its error proneness and could help us to predict faults in the future. To obtain the number of changes made in each feature, we tracked the commits to the Drupal Git repository 3 . The search was narrowed by focusing on the changes performed during a period of two years, from May 1 st 2012 to April 31 st 2014.…”

Section: Non-functional Attributesmentioning

confidence: 99%

“…integration faults. Our first approach was to follow the strategy presented by Artho et al [3] in the context of operating systems. That is, for each feature, we searched for faults descriptions containing the keywords "break", "conflict" or "overwrite".…”

Section: Faults In Drupalmentioning

confidence: 99%

“…In fact, multiple works in the field of soft-ware repository mining have explored the correlations between certain non-functional properties and metrics and the fault propensity of software components [3,30,33,46,49]. In this section, we investigate whether the non-functional attributes presented in Section 4 could be used to estimate the fault propensity of Drupal features.…”

Section: Correlation Studymentioning

confidence: 99%

See 2 more Smart Citations

Variability testing in the wild: the Drupal case study

et al. 2015

View full text Add to dashboard Cite

Variability testing techniques search for effective and manageable test suites that lead to the rapid detection of faults in systems with high variability. Evaluating the effectiveness of these techniques in realistic settings is a must, but challenging due to the lack of variability intensive systems with available code, automated tests and fault reports. In this article, we propose using the Drupal framework as a case study to evaluate variability testing techniques. First, we represent the framework variability using a feature model. Then, we report on extensive non-functional data extracted from the Drupal Git repository and the Drupal issue tracking system. Among other results, we identified 3,392 faults in single features and 160 faults triggered by the interaction of up to 4 features in Drupal v7.23. We also found positive correlations relating the number of bugs in Drupal features to their size, cyclomatic complexity, number of changes and fault history. To show the feasibility of our work, we evaluated the effectiveness of non-functional data for test case prioritization in Drupal. Results show that non-functional attributes are effective at accelerating the detection of faults, outperforming related prioritization criteria as test case similarity.

show abstract

Section: Non-functional Attributesmentioning

confidence: 99%

Section: Faults In Drupalmentioning

confidence: 99%

Section: Correlation Studymentioning

confidence: 99%

See 1 more Smart Citation

Variability testing in the wild: the Drupal case study

et al. 2015

View full text Add to dashboard Cite

show abstract

“…Before looking for similar words (pairwise comparison), one could also put all documents into clusters, where they have at least one common word, and then perform a search within these clusters [63]. And no matter which search technique is used, one should always report possible bias (e.g., the choice of keywords when filtering bug reports) [6] and manually validate a subset of the outcome [19].…”

Section: Text Miningmentioning

confidence: 99%

“…MSR researchers suggest manually inspecting the outcome of automated algorithms. For example, a keyword-based approach for bug report identification [6] and clustering of bug types [65] requires manual verification of the outcome. Otherwise, if the keywords or the search are not suitable for a project, the entire analysis and conclusions are doubtful.…”

Section: Comments From 5 Papers]mentioning

confidence: 99%

The MSR Cookbook: Mining a decade of research

Hemmati

Nadi

Baysal

et al. 2013

2013 10th Working Conference on Mining Software Repositories (MSR)

View full text Add to dashboard Cite

Abstract-The Mining Software Repositories (MSR) research community has grown significantly since the first MSR workshop was held in 2004. As the community continues to broaden its scope and deepens its expertise, it is worthwhile to reflect on the best practices that our community has developed over the past decade of research. We identify these best practices by surveying past MSR conferences and workshops. To that end, we review all 117 full papers published in the MSR proceedings between 2004 and 2012. We extract 268 comments from these papers, and categorize them using a grounded theory methodology. From this evaluation, four high-level themes were identified: data acquisition and preparation, synthesis, analysis, and sharing/replication. Within each theme we identify several common recommendations, and also examine how these recommendations have evolved over the past decade. In an effort to make this survey a living artifact, we also provide a public forum that contains the extracted recommendations in the hopes that the MSR community can engage in a continuing discussion on our evolving best practices.

show abstract