The document provides an overview of code review practices using tools like Gerrit, Egit, and Git, highlighting their collaborative nature and benefits such as bug detection and maintaining code quality. It discusses the roles in the review process and explains the patch lifecycle, along with specific workflows in environments like Linux and Eclipse. Furthermore, it emphasizes the importance of adhering to technical quality and the efficient management of changes through a structured review system.

1. Code Review usingGerrit, EGit and Githttp://code.google.com/p/gerrithttp://eclipse.org/egit+=Matthias Sohn (SAP)matthias.sohn@sap.comTwitter: @masohn

2. OverviewHudson, MylynintegrationToolsany VCS,change management, audit toolsGerritEGit, JGitCVS, SVN, bugzillamailing lists mailing listsmassive peer review review contributionsreview critical areasInteractionbazaarcathedraltechnical qualityover allprotect IP of member companiesclassical QA, governance, regulationsMotivationCode Review | © 2010 by M. Sohn

3. Peer Code Review – What is it ?Guido van Rossum [1]When one developer writes code, another developer is asked to review that codeA careful line-by-line critique Happens in a non-threatening context Goal is cooperation, not fault-finding Often an integral part of coding processDebugging someone else's broken code– Involuntary code review: Not so good; emotions may flare[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdfCode Review | © 2010 by M. Sohn

4. Code Review – BenefitsGuido van Rossum [1]Four eyes catch more bugsCatch bugs early to save hours of debuggingEnforce coding standardsKeep overall readability & code quality highMentoring of new developers Learn from mistakes without breaking stuffEstablish trust relationships Prepare for more delegationGood alternative to pair programmingasynchronous and across locations[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdfCode Review | © 2010 by M. Sohn

5. Review - how does it Linux ?Collected from http://www.linuxfoundation.org/publications/linuxkerneldevelopment.phpCode Review | © 2010 by M. Sohn

6. RolesContributorsProposechangesReview changes(all changesarereviewed)Test, ...MaintainersBenevolent dictatorOneMaintainer per subsystemLieutenant hierarchyFinal decision on inclusionof a changeCode Review | © 2010 by M. Sohn

7. Guiding PrinciplesTechnical quality over allCode quality outweighsCompany plansUser desiresExisting practiceDeveloper statusLong-term viewKernel developers expect to be maintaining the code 5-10 yearsMassive peer reviewNo code is perfectit can always be improvedheed requests forchangesCode Review | © 2010 by M. Sohn

8. Guiding PrinciplesNo ownership of codeEven code you wroteNo regressions...even to fix other problems“So we don't fix bugs by introducing new problems. That way lies madness, and nobody ever knows if you actually make any real progress at all. Is it two steps forwards, one step back, or one step forward and two steps back?”-- Linus TorvaldsNo inherent right to inclusionChanges require justificationOther solutions may win outCode Review | © 2010 by M. Sohn

9. Fundamental unit of work is the patch...Identifies your exact set of changesEncapsulates changes to all modified filesResilient across changes to underlying files© SAP 2009 | 9PatchesCode Review | © 2010 by M. Sohn

10. © SAP 2009 | 10Code Review on Mailing ListCode Review | © 2010 by M. Sohn

11. Patch LifecycleDesignThis is where the real requirements for the patch -- and the way those requirements will be met -- are laid out. Early review Patches are posted to the relevant mailing list, and developers on that list reply with any comments they may have. Wider review When the patch is getting close to ready for mainline inclusion, it will be accepted by a relevant subsystem maintainer -- though this acceptance is not a guarantee that the patch will make it all the way to the mainline.Merging into the mainline Eventually, a successful patch will be merged into the mainline repository. More comments and/or problems may surface at this timeStable release The number of users potentially affected by the patch is now large, so, once again, new problems may arise.Long-term maintenance The original developer should continue to take responsibility for the code if it is to remain useful in the longer term.Code Review | © 2010 by M. Sohn

12. The targetisalwaysthemainlinekernelMaintainer: Linus Torvalds2-3 month release cycleRelease cycle© SAP 2009 | 12TreesCode Review | © 2010 by M. Sohn

13. TreesPatches travel through treesCode Review | © 2010 by M. Sohn

14. Git… a distributed revision control system built by the Linux project to automate patch workflowDistributed means no central repositoryNo central authority!

15. Easy offline usage

16. Easy to fork a project

17. Protected against manipulation by cryptographic hashesReally good at mergingCoordination only needed "after the fact”

18. Easier to rejoin (or refresh) forked projectsStructured around commits (i.e. patches)Integrates with email channel

19. Tools for identifying problem commits (gitbisect)

20. Tools for restructuring branches w/ specific commitsCode Review | © 2010 by M. Sohn

21. Review - how does it Eclipse ?Code Review | © 2010 by M. Sohn

22. The Eclipse WayCopied from Pat Huff (IBM)http://www.eclipsecon.org/2008/sub/attachments/Managing_Eclipse_Adoption_in_the_Enterprise.pdfCode Review | © 2010 by M. Sohn

23. Eclipse - RolesCommitter Formally electedCan commit own changes without reviewContributorSmall changes reviewed by committersBigger changes also formal IP review by legal team in separate protected BugzillaReview Toolpatches attached to bug in Bugzillacomments in BugzillaCode Review | © 2010 by M. Sohn

24. Code Review in BugzillaCode Review | © 2010 by M. Sohn

25. Eclipse – Review ProcessContributorscreate patch using CVS, SVN, Git

26. attach patch to bug in BugzillaCommittersdo code and IP review

27. comment, vote in Bugzilla

28. create CQ for changes needing IP review

29. commit accepted changesIP Teamdoes IP review bigger changes from contributorsCode Review | © 2010 by M. Sohn

30. Eclipse – Review ProcessReview not done for all changesReview tedious for contributors (and also for committers mentoring contributors)Code Review | © 2010 by M. Sohn

31. Git at Eclipse (since 2009)Eclipse defined a roadmap to move to GitEGitis an Eclipse Team provider for Githttp://www.eclipse.org/egit/JGit is a lightweight Java library implementing Githttp://www.eclipse.org/jgit/The goal is to build an Eclipse community around Git.EGit/JGit are still beta and we want to establish a feedback loop to improve the tooling.Code Review | © 2010 by M. Sohn

32. History JGit/EGit2005 Linus Torvalds starts Git2006 Shawn Pearce starts JGit2009 Eclipse decides for Git Roadmap JGit/EGit move to eclipse.org SAP joins3/2010 Released 0.7(first release at Eclipse) Diff/Merge Algorithms, Automatic IP Logs6/2010 Released 0.8 (Helios) Usability Improvements, Git Repositories View, Tagging9/2010Released 0.9 (Helios SR1) Merge, Synchronize View, .gitignorePlanned 12/2010 0.10 3/2011 0.11 6/2011 1.0 (Indigo)Git at Eclipse | © 2010 by M. Sohn

33. Review - How does it look with Gerrit ?Code Review | © 2010 by M. Sohn

34. Gerrit Code ReviewGerritis a Code Review system based on JGithttp://code.google.com/p/gerrit/

35. Also serves as a gitserver

36. adding access control and workflow

37. Used by

38. Androidhttps://review.source.android.com/

39. JGit, EGithttp://egit.eclipse.org/r/

40. Google, SAP, …

41. Eclipse wants to use it …Code Review | © 2010 by M. Sohn

42. History GerritCode ReviewGerrit = 4th Generation code review @ GoogleGoogle started code review with a Linux like review processpatch based

43. tooling based on Perforce CLICode Review | © 2010 by M. Sohn

44. Google - Web based code review toolsMondrian(Guido van Rossum)based on Perforce, Google infrastructure

45. Google proprietaryRietvield(Guido van Rossum)based on Subversion