Mahara started to use Gerrit code revision system recently. All proposed changes to master branch of the project now go through the compulsory revision process that requires approval of the change by the other developers. Adding this revision step in the code committing workflow improves the quality of the committed code and team awareness about the changes and new features. It allows absolutely anyone to contribute to Mahara by committing the patch or new feature directly to the code revision system, getting feedback from the core developers and other people and participate in code revision themselves. Making participation in development process simpler could attract more people to Mahara developers’ community and make Mahara better. The presentation will demonstrate how code revision works. It will display the whole way of the patch from creation on developer’s local system to the merge into master branch through revision and validation. The presentation will cover how to use Gerrit interface, best practices in revision system use, as well as most common scenarios that may occurs during revision process.

1. Mahara UK 2011 – Technical Workshop21st June 2011

2. How Mahara code revision worksRuslan KabalinMahara UK, 21nd June 2011

3. Plan for the next 30 minutesWhere Mahara code is located

4. Old patch submission workflow

5. Gerrit code revision system

6. Why do we need to review the code

7. Revision process

8. Live demo

9. Concluding remarksMahara main repositoryhttp://gitorious.org/mahara/mahara(Image from https://launchpad.net/mahara/+series)

10. How revision was done beforeChange is reviewed and pushed to masterChange is mailedto core developersPatch was submitted using email to the core developers

11. Core developers reviewed and responded with proposed changes

12. Only core developers could push changes to master repo.

13. Those who gained reputation became core developers with push permissionChange appears on master repo

14. Limitations of the old workflowComplicated workflow

15. Takes time

16. No one reviews core developers’ patches

17. Contributors do not feel involvedGerrit code revision systemIntermediate step between master and your local branch

18. Web-based collaborative code revision tool

19. All changes go through revision

20. Revision and verification are required

21. Only Gerrit can push directly to master

22. For your git repo it is just another remote branch** git remote add gerrit ssh://user@reviews.mahara.org:29418/mahara

23. Gerrit simplified workflowChange is pushedto gerrit repoChange appears onrevision interfaceChange is being reviewedChange needs to be updated and resubmittedChange is merged to main repoReviewed & verified?YesNo

24. Reasons for code reviewImprove the quality of the code

25. Mentor each other

26. Learning from others

27. Improve security

28. Remove old code

29. Team awareness about project

30. Attract more developersOpen to everyone!Anybody can submit the change for revision*

31. No specials rights are required

32. Anybody can review someone’s patches

33. Active contributors with good reputation will become core developers* Just do some initial dev tools set up: https://wiki.mahara.org/Developer_Area/Developer_Tools

34. Revision processChange needs to be both revised and verified before being merged into master

35. Anybody can do revision (add revision points)

36. Only Gerrit reviewers (core developers) can mark the change as verifiedGerrit code revision systemGerrit Web Interfacehttps://reviews.mahara.org

37. Pushing your changesSet up dev environmenthttps://wiki.mahara.org/Developer_Area/Contributing_CodePush your change: git push gerritHEAD:refs/for/masterWait for revision of your change patch-set...

38. If not approved, amend the change accordingly and push again (preserve same Change-Id)

39. Wait for revision of your second change patch-set...

40. Update tracker if applicable once the change is mergedLive demoLet’s fix the bug!https://bugs.launchpad.net/mahara/+bug/799768

41. Best practicesIf you want to merge a big feature, break it down into lots of smaller ones (maybe dependencies first, etc.)

42. When pushing patches that are related, use a Gerrit tag

43. Every new patch should be applied on top of the clean checked-out branch to avoid adding dependencies in error

44. When reviewing a series of related patches, keep in mind that the patches after the first rejected one will need to be reviewed againFrom the April IRC dev meeting: http://meetbot.mahara.org/mahara-dev/2011/mahara-dev.2011-04-20-19.40.html

45. Further informationDeveloper tools setup: https://wiki.mahara.org/Developer_Area/Developer_Tools

46. Contributing the code: https://wiki.mahara.org/Developer_Area/Contributing_Code

47. Discussion on the IRC meeting: http://meetbot.mahara.org/mahara-dev/2011/mahara-dev.2011-04-20-19.40.html

48. Mahara code revision system:https://reviews.mahara.org

49. Questions?

50. Thank you!@rkabalinRuslan Kabalin <ruslan.kabalin@luns.net.uk>