deckhand/REVIEWING.rst
Felipe Monteiro 6c45569ecd docs: Add developer overview documentation
This patchset adds developer overview documentation for providing
a high-level introduction to Deckhand, including its architecture,
modules, test utilities, Helm utilities, and other errata. This
work is based off this Drydock patchset:

  https://review.openstack.org/#/c/571298/

Change-Id: Ic3382d4e04edf02a65184651d272fe9cd1db56a4
2018-06-20 15:00:46 -04:00

1.4 KiB

Reviewing Deckhand Code

To start read the OpenStack Common Review Checklist

Unit Tests

For any change that adds new functionality to either common functionality or fixes a bug unit tests are required. This is to ensure we don't introduce future regressions and to test conditions which we may not hit in the gate runs.

Functional Tests

For any change that adds major new functionality functional tests are required. This is to ensure that the Deckhand API follows the contract it promises. In addition, functional tests are run against the Deckhand container, which uses an image built from the latest source code to validate the integrity of the image.

Deprecated Code

Deprecated code should go through a deprecation cycle -- long enough for other Airship projects to modify their code base to reference new code. Features, APIs or configuration options are marked deprecated in the code. Appropriate warnings will be sent to the end user, operator or library user.

When to approve

  • Every patch needs two +2s before being approved.
  • Its OK to hold off on an approval until a subject matter expert reviews it.
  • If a patch has already been approved but requires a trivial rebase to merge, you do not have to wait for a second +2, since the patch has already had two +2s.