how mahara code revision works
DESCRIPTION
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.TRANSCRIPT
Mahara UK 2011 – Technical Workshop21st June 2011
How Mahara code revision works
Ruslan KabalinMahara UK, 21nd June 2011
• Where Mahara code is located• Old patch submission workflow• Gerrit code revision system• Why do we need to review the code• Revision process• Live demo• Concluding remarks
Plan for the next 30 minutes
Mahara main repository
http://gitorious.org/mahara/mahara
(Image from https://launchpad.net/mahara/+series)
How revision was done before
• Patch was submitted using email to the core developers• Core developers reviewed and responded with proposed
changes• Only core developers could push changes to master repo.• Those who gained reputation became core developers with
push permission
Change is mailedto core developers
Change is reviewed and pushed to master
Change appears on master repo
Limitations of the old workflow
• Complicated workflow• Takes time• No one reviews core developers’ patches• Contributors do not feel involved
Gerrit code revision system
• Intermediate step between master and your local branch• Web-based collaborative code revision tool • All changes go through revision• Revision and verification are required• Only Gerrit can push directly to master• For your git repo it is just another remote branch*
* git remote add gerrit ssh://[email protected]:29418/mahara
Gerrit simplified workflow
Change is pushedto gerrit repo
Change appears onrevision interface
Change is being reviewed
Change is merged to main repo
Reviewed & verified?
Change needs to be updated and resubmitted
Yes No
Reasons for code review
• Improve the quality of the code• Mentor each other• Learning from others• Improve security• Remove old code• Team awareness about project• Attract more developers
Open to everyone!
• Anybody can submit the change for revision*• No specials rights are required• Anybody can review someone’s patches• 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
Revision process
• Change needs to be both revised and verified before being merged into master
• Anybody can do revision (add revision points)• Only Gerrit reviewers (core developers) can mark the change
as verified
Gerrit code revision system
Gerrit Web Interface
https://reviews.mahara.org
Pushing your changes
• Set up dev environment
https://wiki.mahara.org/Developer_Area/Contributing_Code• Push your change:
git push gerrit HEAD:refs/for/master• Wait for revision of your change patch-set...• If not approved, amend the change accordingly and push
again (preserve same Change-Id)• Wait for revision of your second change patch-set...• Update tracker if applicable once the change is merged
Live demo
Let’s fix the bug!
https://bugs.launchpad.net/mahara/+bug/799768
Best practices
• If you want to merge a big feature, break it down into lots of smaller ones (maybe dependencies first, etc.)
• When pushing patches that are related, use a Gerrit tag• Every new patch should be applied on top of the clean
checked-out branch to avoid adding dependencies in error• When reviewing a series of related patches, keep in mind that
the patches after the first rejected one will need to be reviewed again
From the April IRC dev meeting: http://meetbot.mahara.org/mahara-dev/2011/mahara-dev.2011-04-20-19.40.html
Further information• Developer tools setup:
https://wiki.mahara.org/Developer_Area/Developer_Tools• Contributing the code:
https://wiki.mahara.org/Developer_Area/Contributing_Code• Discussion on the IRC meeting:
http://meetbot.mahara.org/mahara-dev/2011/mahara-dev.2011-04-20-19.40.html
• Mahara code revision system:
https://reviews.mahara.org
Questions?
