airship
/
deckhand
Code Issues Proposed changes
A configuration management service with support for secrets.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
707 Commits
1 Branch
2.8 MiB
 
 
 
 
Branch: master
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from 'master'
${ noResults }
deckhand/REVIEWING.rst

1.4 KiB
Raw Permalink Blame History

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.