Dev Process
Development Process
The code you write, and the way you present it, are crucial for understanding and maintaining the source code. Please read the following sections for guidelines on Git, Gerrit, patch management and more.
Patch Review Process Goals
The patch review process goals are:
- Improving code quality
- Design improvements
- Openness, transparency, community
- Usable revision history
- Archived discussions
- Patches which can be cherry-picked
The oVirt project uses gerrit in order to review patches. For more on Gerrit and how to use it see Working with oVirt Gerrit
Basic Principles
Review Process
- Patches sent to Gerrit for review
- A peer thoughtfully reviews the patch
- Feedback gratefully received
- All discussions on the patch must be done on Gerrit
- Consensus formed, ACK or NAK agreed
Coding standards
- all coding standards for the project can be found at Backend Coding Standards
who’s my reviewer?
if you don’t know who is should review your patch you can either -
- ping the engine-devel@ovirt.org mailing list with the link to gerrits request
-
git blame your code and trace recent users who committed code that you changed
git blame HEAD~1 path/to/file -L {start},{end}
Patch Format
- ovirt-engine patch format
use the project template for a commit message
git commit -s -t config/engine-commit-template.txt
-
other patch format (VDSM)
short summary under 80 chars
Longer description. With multiple paragraphs if necessary. Wrapped at ~80 chars.
Bug-Url: https://bugzilla.redhat.com/XXXXXX Signed-off-by: full name
Sending a Patch For Work In Progress
Use gerrit’s draft capabilities.
Patches in draft are blocked from being merged until they are “published”
To push a patch to drafts:
git push origin HEAD:refs/drafts/master
Describe your changes properly
- Not just “what”, but “why”
- Makes patches easier to review
- Incredibly useful to future developers, and for you as well (don’t trust your own memory)
Separate your changes
- Each commits contain a single logical change
- Keep refactoring separate from bug fixes
Focus on details
- Adhere to coding style
- Adhere to commit message format
- Make your code beautiful
- Refactor if necessary
- Use whitespaces and not tabs
- Prefer understandable code over comments
Patch queues
- Each topic branch is a patch queue
- Send each branch as a series of patches
- Gives reviewers an easy story to follow
Git guidelines
Merge commits
- Don’t use ‘git merge’ or ‘git pull’
- Use ‘git rebase’ and ‘git fetch’ instead
- A merge commit is rarely what you want
Topic branches
Create a branch for everything you work on. It can be done by either postfixing the topic to the push link
push origin HEAD:refs/publish/master/{NAME_OF_YOUR_TOPIC}
or using gerrit’s review page directly by clicking on the topic
Interactive Rebase
You can also interactive rebase. It is very useful when you would like to re-write your own commit objects before pushing them somewhere. It is an easy way to split, merge or re-order commits before sharing them with others. You can also use it to clean up commits you’ve pulled from someone when applying them locally.
For more information on using interactive rebase see https://book.git-scm.com/docs/git-rebase#_interactive_mode