Predicting Fault Incidence Using Software Change History
IEEE Transactions on Software Engineering
Bugs as deviant behavior: a general approach to inferring errors in systems code
SOSP '01 Proceedings of the eighteenth ACM symposium on Operating systems principles
Understanding and predicting effort in software projects
Proceedings of the 25th International Conference on Software Engineering
ICSE '76 Proceedings of the 2nd international conference on Software engineering
Identifying Reasons for Software Changes Using Historic Databases
ICSM '00 Proceedings of the International Conference on Software Maintenance (ICSM'00)
Robust Prediction of Fault-Proneness by Random Forests
ISSRE '04 Proceedings of the 15th International Symposium on Software Reliability Engineering
Predicting the Location and Number of Faults in Large Software Systems
IEEE Transactions on Software Engineering
Toward Understanding the Rhetoric of Small Source Code Changes
IEEE Transactions on Software Engineering
MSR '05 Proceedings of the 2005 international workshop on Mining software repositories
How long did it take to fix bugs?
Proceedings of the 2006 international workshop on Mining software repositories
Global software development in the freeBSD project
Proceedings of the 2006 international workshop on Global software development for the practitioner
Automatic Identification of Bug-Introducing Changes
ASE '06 Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering
Predicting Defects for Eclipse
PROMISE '07 Proceedings of the Third International Workshop on Predictor Models in Software Engineering
/*icomment: bugs or bad comments?*/
Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles
The influence of organizational structure on software quality: an empirical case study
Proceedings of the 30th international conference on Software engineering
Predicting defects using network analysis on dependency graphs
Proceedings of the 30th international conference on Software engineering
What do large commits tell us?: a taxonomical study of large commits
Proceedings of the 2008 international working conference on Mining software repositories
Predicting failures with developer networks and social network analysis
Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering
Predicting faults using the complexity of code changes
ICSE '09 Proceedings of the 31st International Conference on Software Engineering
Does distributed development affect software quality? An empirical case study of Windows Vista
ICSE '09 Proceedings of the 31st International Conference on Software Engineering
Defect prediction from static code features: current results, limitations, new approaches
Automated Software Engineering
An industrial study on the risk of software changes
Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering
The MSR cookbook: mining a decade of research
Proceedings of the 10th Working Conference on Mining Software Repositories
Replicating mining studies with SOFAS
Proceedings of the 10th Working Conference on Mining Software Repositories
Hi-index | 0.00 |
Modern software is often developed over many years with hundreds of thousands of commits. Commit metadata is a rich source of social characteristics, including the commit's time of day and the experience and commit frequency of its author. The "bugginess" of a commit is also a critical property of that commit. In this paper, we investigate the correlation between a commit's social characteristics and its "bugginess"; such results can be very useful for software developers and software engineering researchers. For instance, developers or code reviewers might be well-advised to thoroughly verify commits that are more likely to be buggy. In this paper, we study the correlation between a commit's bugginess and the time of day of the commit, the day of week of the commit, and the experience and commit frequency of the commit authors. We survey two widely-used open source projects: the Linux kernel and PostgreSQL. Our main findings include: (1) commits submitted between midnight and 4 AM (referred to as late-night commits) are significantly buggier and commits between 7 AM and noon are less buggy, implying that developers may want to double-check their own latenight commits; (2) daily-committing developers produce less-buggy commits, indicating that we may want to promote the practice of daily-committing developers reviewing other developers' commits; and (3) the bugginess of commits versus day-of-week varies for different software projects.