Skip to content

Latest commit

 

History

History
34 lines (25 loc) · 2.19 KB

MAINTAINERS.md

File metadata and controls

34 lines (25 loc) · 2.19 KB

Maintainers

This document aims to assist maintainers.

Envoy domain expertise

As a guideline, concepts in Nighthawk that are derived from Envoy require someone with Envoy domain expertise in review. Notable examples are the way Nighthawk internally computes cluster configuration, its connection pool derivations, the StreamDecoder class, as well as anything related to the Nighthawk test server.

See OWNERS.md to find maintainers with expertise of Envoy internals.

Pre-merge checklist

  • Does the PR have breaking changes? Then that should be explicitly mentioned in the version history.
  • New features should be added to the version history.
  • Breaking changes to the protobuf APIs are not allowed.
  • When merging, clean up the commit message so we get a nice history. By default, github will compile a message from all the commits that are squashed. The PR title and description should be a good starting point for the final commit message. (If it is not, it may be worth asking the PR author to update the description).
  • Make sure that the DCO signoff is included in the final commit message.
    • As a convention, it is appropriate to exclude content in the PR description that occurs after the signoff.

Updates to the Envoy dependency

We try to regularly synchronize our Envoy dependency with the latest revision. Nighthawk reuses large parts of Envoy's build system and CI infrastructure. When we update, that looks like:

  • A change to repositories.bzl to update the commit and SHA.
  • A sync of .bazelrc with Envoy's version to update our build configurations.
  • A sync of the build image sha used in the ci configuration with Envoy's version to sync our CI testing environment.
  • Sometimes the dependency update comes with changes that break our build. We include any changes required to Nighthawk to fix that.