This paper partially replicates prior works on building historical commits [1], commit risk modeling [2], and a comparison of statistical bug models and static bug finders [3].We examine 8 Maven-based projects with an average lifespan of 5.8 years. To historically build these projects across a total of 45k commits, we develop a series of techniques, such as flexibly selecting the version of a library that is closest to the commit date. We are able to build a per project average of 78.4% of all commits, a doubling in buildability compared to prior work. We also develop a git blame strategy to assign warnings even when a commit does not build.We run JLint and FindBugs and create a logistic regression model to predict if a commit that introduces a warning has higher odds of introducing a bug. The static bug finders model accounted for only 13% of the deviance, while the statistical bug model accounted for 19.5%. We had expected static bug finder warnings to improve the predictive power of models of bug introducing changes, but we clearly attained a negative result.To understand this negative result, we perform a preliminary user study of developers who introduced new warnings in 37 projects. We found that while warnings might not predict bugs, 53% and 21% of warnings in Findbugs and Jlint respectively are useful. We also study whether just-in-time warnings presentation on each commit impacted usefulness. We find that the later a warning is shown to a developer, the less useful it is perceived to be (a median of 11.5 days versus 23 days for non useful warnings).Based on our findings, we modify the existing COMMITGURU interface to add new warnings to the specific line in a changed file. The empirical study data [4] and WARNINGSGURU tool [5] are publicly available.

The detection of bugs in software systems has been divided into two research areas: static code analysis and statistical modeling of historical data. Static analysis indicates precise problems on line numbers but has the disadvantage of suggesting many warning which are often false positives. In contrast, statistical models use the history of the system to suggest which files or commits are likely to contain bugs. These course-grained predictions do not indicate to the developer the precise reasons for the bug prediction. We combine static analysis with statistical bug models to limit the number of warnings and provide specific warnings information at the line level. Previous research was able to process only a limited number of releases, our tool, WarningsGuru, can analyze all commits in a source code repository and we currently have processed thousands of commits and warnings. Since we process every commit, we present developers with more precise information about when a warning is introduced allowing us to show recent warnings that are introduced in statistically risky commits. Results from two OSS projects show that CommitGuru's statistical model flags 25% and 29% of all commits as risky. When we combine this with static analysis in WarningsGuru the number of risky commits with warnings is 20% for both projects and the number commits with new warnings is only 3% and 6%. We can drastically reduce the number of commits and warnings developers have to examine. The tool, source code, and demo is available at https://github.com/louisq/warningsguru.

Continuous delivery and rapid releases have led to innovative techniques for integrating new features and bug fixes into a new release faster. To reduce the probability of integration conflicts, major software companies, including Google, Facebook and Netflix, use feature toggles to incrementally integrate and test new features instead of integrating the feature only when it's ready. Even after release, feature toggles allow operations managers to quickly disable a new feature that is behaving erratically or to enable certain features only for certain groups of customers. Since literature on feature toggles is surprisingly slim, this paper tries to understand the prevalence and impact of feature toggles. First, we conducted a quantitative analysis of feature toggle usage across 39 releases of Google Chrome (spanning five years of release history). Then, we studied the technical debt involved with feature toggles by mining a spreadsheet used by Google developers for feature toggle maintenance. Finally, we performed thematic analysis of videos and blog posts of release engineers at major software companies in order to further understand the strengths and drawbacks of feature toggles in practice. We also validated our findings with four Google developers. We find that toggles can reconcile rapid releases with long-term feature development and allow flexible control over which features to deploy. However they also introduce technical debt and additional maintenance for developers.