Work Practices and Challenges in Pull-Based Development: The Integrator's Perspective

Gousios, Georgios; Zaidman, Andy; Storey,; Deursen, Arie van

doi:10.1109/icse.2015.55

Cited by 270 publications

(380 citation statements)

References 22 publications

Supporting

Mentioning

366

Contrasting

Order By: Relevance

“…Why do developers apparently go against this norm? Previous work on developer usage of pull requests [25,39] might provide an indication about potential reasons. In a "fail early, fail often" approach, integrators and contributors overwhelmingly rely on their tests to assess the quality of contributed code.…”

Section: Resultsmentioning

confidence: 99%

“…If a build is running while a newer commit is pushed to the same branch, TRAVIS CI immediately cancels the execution of the current build and starts building the latest relevant commit. This seamless integration into projects' workflow caters for the popular pull request model [25] and is supposedly key to TRAVIS CI's popularity among GITHUB projects.…”

Section: Travis CImentioning

confidence: 99%

See 1 more Smart Citation

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Beller

Gousios

Zaidman

2016

Preprint

Self Cite

View full text Add to dashboard Cite

Continuous Integration (CI) has become a best practice of modern software development.At present, we have a shortfall of insight into the testing practices that are common in CIbased software development. In particular, we seek quantifiable evidence on how central testing really is in CI, how strongly the project language influences testing, whether different integration environments are valuable and if testing on the CI can serve as a surrogate to local testing in the IDE. In an analysis of 2,640,825 Java and Ruby builds on Travis CI, we find that testing is the single most important reason why builds fail.Moreover, the programming language has a strong influence on both the number of executed tests, their test run time and proneness to fail. The use of multiple integration environments leads to 10% more failures being caught at build time. However, testing in the CI does not seem to be a good surrogate for running tests in the IDE.

show abstract

Section: Resultsmentioning

confidence: 99%

Section: Travis CImentioning

confidence: 99%

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Beller

Gousios

Zaidman

2016

Preprint

Self Cite

View full text Add to dashboard Cite

show abstract

“…In addition, GitHub also provides various software project development data. Hence, the data of GitHub has been widely used in previous studies [26][27][28][29][30].…”

Section: Subject Projectsmentioning

confidence: 99%

Understanding Review Expertise of Developers: A Reviewer Recommendation Approach Based on Latent Dirichlet Allocation

Kim

Lee

2018

Symmetry

View full text Add to dashboard Cite

Abstract:The code reviewer assignment problem affects the reviewing time of a source code change. To effectively perform the code review process of a software project, the code reviewer assignment problem must be dealt with. Reviewer recommendation can reduce the time required for finding appropriate reviewers for a given source code change. In this paper, we propose a reviewer recommendation approach based on latent Dirichlet allocation (LDA). The proposed reviewer recommendation approach consists of a review expertise generation phase and a reviewer recommendation phase. The review expertise generation phase generates the review expertise of developers for topics of source code changes from the review history of a software project. The reviewer recommendation phase computes the review scores of the developers according to the topic distribution of a given source code change and the review expertise of the developers. In an empirical evaluation of five open source projects, we confirm that the proposed reviewer recommendation approach obtains better average top-10 accuracy than existing reviewer recommendation approaches.

show abstract

“…Besides these results are useful for development in general, there are no catalogs focused specifically on integration. A recent survey [GZSvD15] proposes some questions to characterize pull requests but the authors do not focus on a systematic characterization of questions that integrators ask themselves. There is not enough research done for knowing qualitatively and quantitatively these challenges.…”

Section: Introductionmentioning

confidence: 99%

“…This activity is called integration. Integration of changes is a difficult activity and poses substantial challenges [UG12,GZSvD15]. Focused on understanding development challenges, several research works [LM10, PTL + 11, SMDV08, FM10] systematically characterize what questions developers need to answer when working.…”

Section: Introductionmentioning

confidence: 99%

Do Tools Support Code Integration? A Survey.

Dias¹,

Ducasse²,

Cassou³

et al. 2016

JOT

View full text Add to dashboard Cite

Integrating changes made by other developers is a difficult and tedious process. To understand how to help integrators, we first need to know the main questions they ask themselves while integrating and then relate these questions to the tool support that is needed. With this information, researchers and tool developers will be able to focus on the important questions that have little tool support.In this paper, we report on a 2-step study. In the first step, we did an open call to integrators. We ask them to list questions they ask themselves when they integrate a change. In the second step, based on the questions gathered during the first step and a literature survey, we built a list of 46 questions and run a survey to rank the importance of each question and if the level of tool support was adequate. We present the results we collected. Additionally, we present a taxonomy of the questions according to the kind of information that tools need to answer such questions.We found out that some questions like "Who is the author of this changed code?" are important and have good tool support whereas others like "Do all the changes within the commit belong together? (Can we split the commit?)" are moderately to extremely important and have no tool support.

show abstract

Work Practices and Challenges in Pull-Based Development: The Integrator's Perspective

Cited by 270 publications

References 22 publications

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Understanding Review Expertise of Developers: A Reviewer Recommendation Approach Based on Latent Dirichlet Allocation

Do Tools Support Code Integration? A Survey.

Contact Info

Product

Resources

About