A case study of open source software development: the Apache server
Proceedings of the 22nd international conference on Software engineering
Detecting Patch Submission and Acceptance in OSS Projects
MSR '07 Proceedings of the Fourth International Workshop on Mining Software Repositories
Open source software peer review practices: a case study of the apache server
Proceedings of the 30th international conference on Software engineering
Proceedings of the 2008 international working conference on Mining software repositories
The promises and perils of mining git
MSR '09 Proceedings of the 2009 6th IEEE International Working Conference on Mining Software Repositories
Characterizing and predicting which bugs get fixed: an empirical study of Microsoft Windows
Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 1
Predicting the fix time of bugs
Proceedings of the 2nd International Workshop on Recommendation Systems for Software Engineering
Proactive detection of collaboration conflicts
Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering
Identifying Linux bug fixing patches
Proceedings of the 34th International Conference on Software Engineering
The effect of branching strategies on software quality
Proceedings of the ACM-IEEE international symposium on Empirical software engineering and measurement
Assessing the value of branches with what-if analysis
Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering
An Empirical Study on Factors Impacting Bug Fixing Time
WCRE '12 Proceedings of the 2012 19th Working Conference on Reverse Engineering
Hi-index | 0.00 |
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 integra- tion 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 cross- links 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.