Software Archeology @ RIT
Review Participation
We have been continuing to expand upon our current number of histograms, which show us quick details about our data. Using that data, we have been able to learn a good deal about the information we’d scraped a while back. As we continue to think of new ideas for what type of graphs/comparisons might be useful, we learn more and more about chromium software development.
A histogram we made recently shows the number of nonparticipating reviewers in a code review. The chart can be seen here:
This histogram is particularly interesting, because as you can see the number of code reviews with one or two nonparticipating reviewers is very high! As far as percentages, that means approximately 59.9% of code reviews have one nonparticipating reviewer. What’s more extraordinary is when you look at another one of our histograms, number of reviewers per code review, a large number of code reviews only have one reviewer. Could this mean there exist some reviews that were assigned one reviewer and that person never participated? This is something interesting to consider.
Expanding on Code Familiarity
Another interesting development this week is we have been able to get sheriff rotation information!
As a quick recap, a sheriff is someone who is assigned to monitor the trunk and ensure its health by tracking down people who break the build. There are different types of sheriffs, from memory sheriff to generic “chromium sheriff.” To learn more about chromium sheriffs, see http://dev.chromium.org/developers/tree-sheriffs.
After being added to the chromium sheriff calendars, we were able to scrape each sheriff rotation calendar event from 2008 to now and put it in an excel spreadsheet. Each event contains the emails/names of who will be sheriff during that rotation.
Using this information, we can expand upon other metrics. For instance, being a sheriff could indicate increased code familiarity in a particular area if they have to deal with a broken build. Later, if that previous sheriff is included in a code review related to the same code area, we can investigate whether or not that decreases the chances of a vulnerability being introduced. Perhaps the sheriff had some experience interacting with experienced developers in this section of code and can more easily determine what will introduce a vulnerability.
Additionally, if we do look more into social familiarity and transfer of knowledge, we could look into whether knowing someone who was a sheriff improves ones own software development
This project is sponsored by the Collaborative Research Experiences for Undergraduates, funded by the National Science Foundation.