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.

How Mahara code revision works


Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

How Mahara code revision works

  1. 1. Mahara UK 2011 – Technical Workshop21st June 2011<br />
  2. 2. How Mahara code revision works<br />Ruslan Kabalin<br />Mahara UK, 21nd June 2011<br />
  3. 3. Plan for the next 30 minutes<br /><ul><li>Where Mahara code is located
  4. 4. Old patch submission workflow
  5. 5. Gerrit code revision system
  6. 6. Why do we need to review the code
  7. 7. Revision process
  8. 8. Live demo
  9. 9. Concluding remarks</li></li></ul><li>Mahara main repository<br /><br />(Image from<br />
  10. 10. How revision was done before<br />Change is reviewed and pushed to master<br />Change is mailed<br />to core developers<br /><ul><li>Patch was submitted using email to the core developers
  11. 11. Core developers reviewed and responded with proposed changes
  12. 12. Only core developers could push changes to master repo.
  13. 13. Those who gained reputation became core developers with push permission</li></ul>Change appears on master repo<br />
  14. 14. Limitations of the old workflow<br /><ul><li>Complicated workflow
  15. 15. Takes time
  16. 16. No one reviews core developers’ patches
  17. 17. Contributors do not feel involved</li></li></ul><li>Gerrit code revision system<br /><ul><li>Intermediate step between master and your local branch
  18. 18. Web-based collaborative code revision tool
  19. 19. All changes go through revision
  20. 20. Revision and verification are required
  21. 21. Only Gerrit can push directly to master
  22. 22. For your git repo it is just another remote branch*</li></ul>* git remote add gerrit ssh://<br />
  23. 23. Gerrit simplified workflow<br />Change is pushed<br />to gerrit repo<br />Change appears on<br />revision interface<br />Change is being reviewed<br />Change needs to be updated and resubmitted<br />Change is merged to main repo<br />Reviewed & verified?<br />Yes<br />No<br />
  24. 24. Reasons for code review<br /><ul><li>Improve the quality of the code
  25. 25. Mentor each other
  26. 26. Learning from others
  27. 27. Improve security
  28. 28. Remove old code
  29. 29. Team awareness about project
  30. 30. Attract more developers</li></li></ul><li>Open to everyone!<br /><ul><li>Anybody can submit the change for revision*
  31. 31. No specials rights are required
  32. 32. Anybody can review someone’s patches
  33. 33. Active contributors with good reputation will become core developers</li></ul>* Just do some initial dev tools set up:<br />
  34. 34. Revision process<br /><ul><li>Change needs to be both revised and verified before being merged into master
  35. 35. Anybody can do revision (add revision points)
  36. 36. Only Gerrit reviewers (core developers) can mark the change as verified</li></li></ul><li>Gerrit code revision system<br />Gerrit Web Interface<br /><br />
  37. 37. Pushing your changes<br /><ul><li>Set up dev environment</li></ul><br /><ul><li>Push your change: </li></ul>git push gerritHEAD:refs/for/master<br /><ul><li>Wait for revision of your change patch-set...
  38. 38. If not approved, amend the change accordingly and push again (preserve same Change-Id)
  39. 39. Wait for revision of your second change patch-set...
  40. 40. Update tracker if applicable once the change is merged</li></li></ul><li>Live demo<br />Let’s fix the bug!<br /><br />
  41. 41. Best practices<br /><ul><li>If you want to merge a big feature, break it down into lots of smaller ones (maybe dependencies first, etc.)
  42. 42. When pushing patches that are related, use a Gerrit tag
  43. 43. Every new patch should be applied on top of the clean checked-out branch to avoid adding dependencies in error
  44. 44. When reviewing a series of related patches, keep in mind that the patches after the first rejected one will need to be reviewed again</li></ul>From the April IRC dev meeting:<br />
  45. 45. Further information<br /><ul><li>Developer tools setup:
  46. 46. Contributing the code:
  47. 47. Discussion on the IRC meeting:
  48. 48. Mahara code revision system:</li></ul><br />
  49. 49. Questions?<br />
  50. 50. Thank you!<br />@rkabalin<br />Ruslan Kabalin <><br />