Skip to content
This repository has been archived by the owner on Oct 1, 2018. It is now read-only.

HOWTO: Fixing a bug

Z edited this page Aug 14, 2014 · 1 revision

This article describes standard Snow Crash issue fixing procedure. Assuming the issue fix should go into master (default), in the rare case some other branch should be used, substitute master mentions with the appropriate branch.

Fixing an Issue

  1. Reproduce the bug using the snowcrash CLI tool
  2. If the bug does not have an GitHub issue create a new one
  3. Pull the latest master from upstream
  4. Create bug fixing branch with the name <your github user name>/<issue name> – the <issue name> can be some reasonable abbreviated version of the issue name
  5. In the new branch, create a unit test reproducing the issue (the test must be failing)
  6. Fix the issue (therefore the unit test)
  7. Verify all the unit tests and integration tests are passing
  8. Commit the fix, use descriptive commit message including any additional comment, use a keyword in the commit message to close the respective issue – the issue will be closed automatically once the commit is merged.
  9. Push into origin, verify all CI tests are passing,
  10. If needed, rebase the fix branch on top of the actual original branch
  11. Create a pull request, be as much descriptive as possible
  12. Take a break, code review may take some time and not happen immediately

Code Review

In the case a change to a PR code is needed:

  1. Perform the change
  2. Commit with some reasonable message & push to origin
  3. Do not rebase (squash) the commit immediately as it will be easier to do the review
  4. Once the PR code review is OK, it is generally a good idea to squash all the review fix commits into the original issue-fixing commit

Coding Standards

  1. Follow Snow Crash Coding Standards
  2. The tests blueprint snippets should be valid blueprints, unless you are performing an invalid blueprint test
Clone this wiki locally