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

2 February 6, 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 February 6, 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 February 6, 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 February 6, 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 February 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 February 6, 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 February 6, 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 February 6, 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 February 6, 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 ● ● ●