Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Role of Patch Review in Software Evolution: An Analysis of the Mozilla Firefox


Published on

Patch review is the basic mechanism for validating the design and implementation of patches and maintaining consistency in some commercial and Free/Libre/Open Source Software (FLOSS) projects. We examine the inner-workings of the development process of the successful and mature Mozilla foundation and highlight how different parties involved affect and steer the process. Although reviewers are the primary actors in the patch review process, success in the process can only be achieved if the community supports reviewers adequately. Peer developers play the supporting role by offering insight and ideas that help create more quality patches. Moreover, they reduce the huge patch backlog reviewers have to clear by identifying and eliminating immature patches.

Published in: Technology

The Role of Patch Review in Software Evolution: An Analysis of the Mozilla Firefox

  1. 1. The Role of Patch Review in Software Evolution: An Analysis of the Mozilla Firefox<br />IWPSE-EVOL 2009, Amsterdam, The Netherlands <br />Mehrdad Nurolahzade<br />SeyedMehdiNasehi<br />Shahedul Huq Khandkar <br />ShreyaRawal<br />
  2. 2. Patch Review<br />The process of incrementally submitting and integrating patches (fix for a bug report) into a software system is a core activity related to software evolution.<br />It act as a basic mechanism for validating the design and implementation of patches.<br />It happens in both, commercial and FLOSS projects.<br />2<br />
  3. 3. Research Questions<br />What are the roles of various people involved in the patch review process?<br />What is the process of conducting reviews?<br />When are reviews performed?<br />What do reviewers look at and what do they miss? <br />3<br />
  4. 4. Mozilla Firefox<br />One of the successful FLOSS projects<br /><ul><li> Second most popular web browser</li></ul> Has both open source and commercial characteristics <br /><ul><li>37% of code is contributed by the community</li></ul>40 developers in Mozilla Corporation Firefox development team<br />100 daily contributors (approx)<br />1000 contributors (approx)<br />20-30 million users (approx)<br />100,000 lines of code (approx) <br />4<br />Source: Mike Beltzner, Mozilla Corporation, Web 2.0 Expo 2007<br />
  5. 5. Software Evolution in Mozilla<br />5<br />
  6. 6. Mozilla Development Process <br />review?, super-review?, ui-review?<br />negative review<br />backed out by QA<br />review+, super-review+, ui-review+<br />6<br />
  7. 7. Overview of Research Approach<br />7<br />Online Mozilla Bugzilla Documentation<br />Bug Reports<br />Codes:<br />Review<br />Negative Review<br />Rubber Stamp<br />Merciful reviewer<br />Open Coding<br />Process<br />Themes<br />Tool for Qualitative Analysis<br />Observations and Patterns<br />Database<br />Quantification<br />
  8. 8. Data Collection<br />8<br />History (Status Changes)<br />Attachments (Patches)<br />Discussion and Comments<br />Bug Report<br />
  9. 9. Tool for Qualitative Analysis<br />9<br />
  10. 10. Data Set<br />10<br />Bug Reports (112) (2002-2009)<br />66 Bugs<br />38 Enhancements<br />8 New Features<br />Patches (310)<br />Comments (1842)<br />318 Reviews<br />
  11. 11. Findings<br />Patterns <br />Patchy Patcher<br />Merciful Reviewer<br />Doubtful reviewer<br />Observations<br />Module Owner Reviews<br />Peer Reviews<br />Types of Feedback<br />Undiscovered Errors<br />11<br />
  12. 12. Patterns: Patchy Patcher<br />12<br /><ul><li>Submits work-in-progress patches
  13. 13. To get early feedback</li></ul>“incomplete, still waiting for Feedback” (Bug # 343172)<br /><ul><li>To show involvement </li></ul>“New patch coming soon…” (Bug # 456214)<br />“wip:0.1 works, but I need to fix …” (Bug # 390614)<br />
  14. 14. Patterns: Merciful Reviewer<br />When reviewers are reluctant to give a review minus (review-).<br /><ul><li>56 negative reviews
  15. 15. 42 review-
  16. 16. Where did the 14 reviews go?</li></ul>After the review comments the reviewer changed the status from ‘review?’ to nothing.<br /> Hypothesis: Module Owners refrain from giving review- to Newcomers<br />13<br />
  17. 17. Pattern: Doubtful Reviewer<br />There has not been enough early feedback from community.<br />A change to functionality is being made.<br />“Let&apos;s put this in for beta, and make sure we blog about the change a little and see the reaction” (Bug # 412862)<br />14<br />
  18. 18. Observation: Module Owner Reviews<br />Every completed patch has to be reviewed by Module Owners unless somebody finds a flaw in it.<br />38 Module Owners<br />198 Code or UI inspections<br />Module owners do not consider patches based on bug report priority (but developers do).<br />15<br />
  19. 19. Observation: Peer Reviews<br />66 Peer Developers<br />Most patches (76%) do not get any Peer Review<br />80% of the comments by peers are negative or partly negative<br />On an average Peer conducts review before Module Owners<br />16<br />
  20. 20. Observation: Types of Reviewer Feedback<br />17<br />Hypothesis: While peers are interested in functionality and usability, Module Owners are also interested in long-term maintainability of the product.<br />
  21. 21. Observation: Undiscovered Errors<br />8.4% of checked-in patches were backed out.<br />Performance and regression issues that remain unidentified during the review.<br />It would be interesting to look if there a common pattern in occurrence of undiscovered errors?<br /> &quot;Based on the site breakage, re-opening and suggesting we back out this change.“ (Bug # 412862)<br />18<br />
  22. 22. Conclusion<br />Peers play a key role in the process by providing ideas before a patch is developed and reviewing developed patches before module owners do.<br />19<br />
  23. 23. Conclusion<br />Module owners are more inclined toward the quality and consistency of developed patches. <br />20<br />
  24. 24. Take Away<br /> Module owners and peer developers are complementing each other in reviewing patches. They refine the developed solution based on their own interests and concerns.<br />21<br />
  25. 25. Debate Questions<br />How quantitative/qualitative analysis of software engineering data can be facilitated?<br />How empirical findings can be cross-validated with the FLOSS development communities?<br />22<br />