1. 1 February 6, 2008 1 Patch Submission and Review Process William Cohen NCSU CSC 591W February 11, 2008

2. 2 February 6, 2008 2 Open Source Software ● Permissive licenses allow: ● Anyone to inspect the code ● Anyone to produce changes to code ● Anyone could have their own version: ● License allows forks of code ● Maintaining separate code base has overhead ● Want to merge changes into mainline version: ● Make use of other people's improvements ● Reduce overhead of maintaining separate version(s)

3. 3 February 6, 2008 3 Patches ● Concisely describe the changes made to the software ● Generated either by comparing: ● Different files or directory on local machine ● Comparing files to software repository ● Allow changes to be applied to different versions of the software

4. 4 February 6, 2008 4 Patch Guidelines ● Detail of review varies by project ● Common elements for various OSS projects: ● Project coding standards specified ● Matching updates to documentation ● Patches focused fixing one issue ● Patch submitter may needs to resubmit at intervals (patches get dropped on mailing lists)

5. 5 February 6, 2008 5 Putting Patch into Code Repository ● Revision control systems have access control: ● Random people cannot check into code ● Some developers may only be able to check code into some area ● Some developers may have global write privileges ● New people usually need developer with write privileges to check in change ● Developers give new person access to code repository when: ● New person has record of developing good code ● New person has done required paperwork (e.g. Copyright assignment)

6. 6 February 6, 2008 6 GCC Patch Submission ● Requires run of test suite for patch ● Verify patch does not break things ● Centralize repository ● Code repository write permission: ● Global write privileges ● Relatively few developers ● No approval required ● Local write privileges: ● Authorized to check in changes in the areas their areas without approval ● Changes in other areas require approval ● Write after approval: ● All changes need review before check in

7. 7 February 6, 2008 7 Linux Kernel Patch Submission ● Uses distributed repository ● Mainline version maintained by Linus Torvald ● Trusted people feed Linus changes via their repositories ● Patch submitters or reviewer need to check mainline Linux repository for their changes (generally no ack) ● Informal testing of kernel patches

8. 8 February 6, 2008 8 Mozilla Patch Submission ● Two levels of review: ● Module review ● Super review ● Perform daily builds on Linux, Windows, and Mac OSX ● Quick feedback if anything breaks ● Code submitters need to be available to fix issues ● Manual “smoke” testing

9. 9 February 6, 2008 9 Apache Patch Submission ● Type review approaches: ● Commit-then-review ● Review-then-commit ● Commit-then-review: ● Used for development version ● Developer checks in code ● Other developers evaluate code (and any can veto change to revert it) ● Review-then-commit ● Used for released version and major changes ● Require concensus, three positive and no negative votes

10. 10 February 6, 2008 10 Further Reading ● Patch Review in Open Source Software Development Communities: A Comparative Case Study by Jai Asundi and Rajiv Jayant ● A preliminary examination of code reivew processes in open source projects by Peter C. Rigby and Daniel German ● http://kernelnewbies.org/UpstreamMerge http://kernelnewbies.org/UpstreamMerge ● http://gcc.gnu.org/contribute.html http://gcc.gnu.org/contribute.html ● http://developer.mozilla.org/en/docs/Code_Review_FAQ http://developer.mozilla.org/en/docs/Code_Review_FAQ