Mining usage data and development artifacts

Baysal,; Holmes,; Godfrey, A.

doi:10.1109/msr.2012.6224305

Cited by 18 publications

(16 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…committer corresponds to the number of different people committing (and hence probably involved in reviewing) chunks of a patch, whereas nr_ccs refers to the number of people suggested as reviewer by putting them into the list of cc-ed email addresses. Hence, the choice of reviewers indeed plays an important role in reviewing time [2]. Finally, experience again plays a major role.…”

Section: Rq3: What Kind Of Patch Is Accepted Faster?mentioning

confidence: 99%

“…Those patches only represent the "lucky few". Studies on Apache and other open source systems have shown how only 40% of the patches considered for integration eventually succeed [2], [3], [4].…”

Section: Introductionmentioning

confidence: 99%

“…The patches first need to pass a gate-keeper who performs a review of the code [2], [5], [6], before the code is merged by an integrator (e.g., release engineer) into the corresponding branch of the open source project [7], [8], [9]. Code reviews fail when a patch does not implement a relevant, working feature or bug fix, or when the project's development guidelines are not followed [10].…”

Section: Introductionmentioning

confidence: 99%

“…Yet, determining up front whether a patch will make it, and how long it will take, is a grey area. Research on code reviews has shown how small patches [6], [4] sent by experienced developers [2] are more likely to be accepted by the reviewers, but it is not clear if these characteristics play the same role during the actual integration of the patch with other patches. Similarly, the impact of these characteristics on the time it takes to get a patch into a release is unclear.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Will my patch make it? And how fast? Case study on the Linux kernel

Jiang

Adams

Germán

2013

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

102

View full text Add to dashboard Cite

The Linux kernel follows an extremely distributed reviewing and integration process supported by 130 developer mailing lists and a hierarchy of dozens of Git repositories for version control. Since not every patch can make it and of those that do, some patches require a lot more reviewing and integration effort than others, developers, reviewers and integrators need support for estimating which patches are worthwhile to spend effort on and which ones do not stand a chance. This paper crosslinks and analyzes eight years of patch reviews from the kernel mailing lists and committed patches from the Git repository to understand which patches are accepted and how long it takes those patches to get to the end user. We found that 33% of the patches makes it into a Linux release, and that most of them need 3 to 6 months for this. Furthermore, that patches developed by more experienced developers are more easily accepted and faster reviewed and integrated. Additionally, reviewing time is impacted by submission time, the number of affected subsystems by the patch and the number of requested reviewers.

show abstract

Section: Rq3: What Kind Of Patch Is Accepted Faster?mentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Will my patch make it? And how fast? Case study on the Linux kernel

Jiang

Adams

Germán

2013

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

102

View full text Add to dashboard Cite

show abstract

“…Finally, researchers suggest normalization in many scenarios. For example, when studying some phenomena concerning browsers or operating systems, you may normalize the data per browser/operating system by its average market share [7]. A2: Correlation analysis can be used to quickly check initial hypotheses about a set of data.…”

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