Paladin/Workflow
From MozillaWiki
< Paladin
Very much a first draft, wants feedback...
For Gladius, Navigame, and other bits that don't already have a defined workflow:
Contents
Basic git workflow
- Create a topic branch in your own fork.
- Write automated tests & code.
- Submit a pull-request to get feedback/review from a project/module owner.
Contributor : making a pull request
- Please make sure that your editor has tabstop 4 and tabs as spaces (except for Makefiles).
- Verify that all existing unit tests pass.
- Make sure you provide new unit tests or changes to existing unit tests.
- (When we have a code coverage tool in place:) Verify that unit test coverage is not reduced by your change set.
- Run make and make check-lint.
- Compose a concise description of your change set. We want to make sure that it does what you said, and doesn't do things that you didn't say.
Reviewer : accepting a pull request
- Create a new local branch containing the requested change set.
- Review the change set. See Testing and review.
- Verify that all unit tests pass.
- Verify that make and make check-lint are successful.
- Make any additional changes in your local branch and commit them before merging the entire change set to the upstream branch.
Testing and review
- Pull requests should be code-reviewed before they land. An exception to this is if they've been pair-programmed with the module-owner/reviewer. We've had good luck (though not yet a lot of experience) using Skype screen-sharing with audio for remote pairing so far.
- Pull requests should include automated tests unless there are compelling reasons not to (eg unlikely to break, testing very hard or impossible). For web-based code, we're already using QUnit for unit tests. We're currently investigating using FuncUnit (which builds on top of QUnit) for functional testing, preliminary tests are looking good.
- If there is no easy way to test important functionality, file an issue/chore in the appropriate place to find or build an appropriate testing framework.
Pairing
Branch model for releases
http://nvie.com/posts/a-successful-git-branching-model/ has good buzz around it; we're going to investigate this more soon.