Paladin/Workflow

From MozillaWiki
Jump to: navigation, search
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

Very much a first draft, wants feedback...

For Gladius, Navigame, and other bits that don't already have a defined workflow:

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.