From 8adda5d39af4d235d7c21705458de5dc39c8a3e8 Mon Sep 17 00:00:00 2001 From: Otto van der Schaaf Date: Sun, 15 Dec 2019 22:25:49 +0100 Subject: [PATCH 1/7] First stab at MAINTAINERS.md - A pre-merge checklist - Documents what goes into an update to the Envoy dependency Fixes https://github.com/envoyproxy/nighthawk/issues/230 Signed-off-by: Otto van der Schaaf --- MAINTAINERS.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 MAINTAINERS.md diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 000000000..330a5f726 --- /dev/null +++ b/MAINTAINERS.md @@ -0,0 +1,18 @@ +# Maintainers + +This document aims to assist maintainers. + +## Pre-merge checklist + +- Does the PR have breaking changes? Then that should be made explicit and mentioned on top in the [version history](docs/root/version_history.md). +- New features should be added to the [version history](docs/root/version_history.md). +- Breaking changes to the [proto apis](api/) are not allowed. + +## Updates to the Envoy dependency + +We try to regularly synchronize our Envoy dependency with the latest revision. When we do so, that looks like: + +- A change to [repositories.bzl](bazel/repositories.bzl) to update the commit and SHA. +- A sync of [.bazelrc](.bazelrc) +- A sync of the build image sha used in the [ci configuration](.circleci/config.yml). +- Any changes required to Nighthawk From 47762c35abc7591cc02d4ed607d40c883b5c423a Mon Sep 17 00:00:00 2001 From: Otto van der Schaaf Date: Mon, 16 Dec 2019 23:18:25 +0100 Subject: [PATCH 2/7] Review feedback: CONTRIBUTING.md & OWNERS.md Signed-off-by: Otto van der Schaaf --- CONTRIBUTING.md | 174 ++++++++++++++++++++++++++++++++++++++++++++++++ MAINTAINERS.md | 4 +- OWNERS.md | 12 ++++ 3 files changed, 188 insertions(+), 2 deletions(-) create mode 100644 CONTRIBUTING.md create mode 100644 OWNERS.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000000000..bb73c451a --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,174 @@ +We welcome contributions from the community. Please read the following guidelines carefully to +maximize the chances of your PR being merged. + +# Communication + +* Before starting work on a major feature, please reach out to us via GitHub, Slack, + email, etc. We will make sure no one else is already working on it and ask you to open a + GitHub issue. +* Small patches and bug fixes don't need prior communication. + +# Coding style + +* Coding style mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/STYLE.md) + +# Breaking change policy + +Both API and implementation stability are important to Nighthawk. Since the API is consumed by clients beyond Nighthawk, breaking changes to that are prohibited. + +# Submitting a PR + +* Fork the repo. +* Create your PR. +* Tests will automatically run for you. +* We will **not** merge any PR that is not passing tests. +* PRs are expected to have 100% test coverage for added code. This can be verified with a coverage + build. If your PR cannot have 100% coverage for some reason please clearly explain why when you + open it. +* Any PR that changes user-facing behavior **must** have associated documentation in [docs](docs) as + well as [release notes](docs/root/intro/version_history.rst). +* All code comments and documentation are expected to have proper English grammar and punctuation. + If you are not a fluent English speaker (or a bad writer ;-)) please let us know and we will try + to find some help but there are no guarantees. +* Your PR title should be descriptive, and generally start with a subsystem name followed by a + colon. Examples: + * "docs: fix grammar error" + * "http conn man: add new feature" +* Your PR description should have details on what the PR does. If it fixes an existing issue it + should end with "Fixes #XXX". +* When all of the tests are passing and all other conditions described herein are satisfied, a + maintainer will be assigned to review and merge the PR. +* Once you submit a PR, *please do not rebase it*. It's much easier to review if subsequent commits + are new commits and/or merges. We squash rebase the final merged commit so the number of commits + you have in the PR don't matter. +* We expect that once a PR is opened, it will be actively worked on until it is merged or closed. + We reserve the right to close PRs that are not making progress. This is generally defined as no + changes for 7 days. Obviously PRs that are closed due to lack of activity can be reopened later. + Closing stale PRs helps us to keep on top of all of the work currently in flight. + +# PR review policy for maintainers + +* Typically we try to turn around reviews within one business day. +* See [OWNERS.md](OWNERS.md) for the current list of maintainers. +* It is generally expected that a maintainer should review every PR. +* The above rules may be waived for PRs which only update docs or comments, or trivial changes to + tests and tools (where trivial is decided by the maintainer in question). +* If there is a question on who should review a PR please discuss in Slack. +* Anyone is welcome to review any PR that they want, whether they are a maintainer or not. +* Please **clean up the title and body** before merging. By default, GitHub fills the squash merge + title with the original title, and the commit body with every individual commit from the PR. + The maintainer doing the merge should make sure the title follows the guidelines above and should + overwrite the body with the original extended description from the PR (cleaning it up if necessary) + while preserving the PR author's final DCO sign-off. + +# DCO: Sign your work + +Envoy ships commit hooks that allow you to auto-generate the DCO signoff line if +it doesn't exist when you run `git commit`. Simply navigate to the Envoy project +root and run: + +```bash +./support/bootstrap +``` + +From here, simply commit as normal, and you will see the signoff at the bottom +of each commit. + +The sign-off is a simple line at the end of the explanation for the +patch, which certifies that you wrote it or otherwise have the right to +pass it on as an open-source patch. The rules are pretty simple: if you +can certify the below (from +[developercertificate.org](https://developercertificate.org/)): + +``` +Developer Certificate of Origin +Version 1.1 + +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. +660 York Street, Suite 102, +San Francisco, CA 94110 USA + +Everyone is permitted to copy and distribute verbatim copies of this +license document, but changing it is not allowed. + + +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, I certify that: + +(a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + +(b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + +(c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + +(d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. +``` + +then you just add a line to every git commit message: + + Signed-off-by: Joe Smith + +using your real name (sorry, no pseudonyms or anonymous contributions.) + +You can add the sign off when creating the git commit via `git commit -s`. + +If you want this to be automatic you can set up some aliases: + +```bash +git config --add alias.amend "commit -s --amend" +git config --add alias.c "commit -s" +``` + +## Fixing DCO + +If your PR fails the DCO check, it's necessary to fix the entire commit history in the PR. Best +practice is to [squash](https://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html) +the commit history to a single commit, append the DCO sign-off as described above, and [force +push](https://git-scm.com/docs/git-push#git-push---force). For example, if you have 2 commits in +your history: + +```bash +git rebase -i HEAD^^ +(interactive squash + DCO append) +git push origin -f +``` + +Note, that in general rewriting history in this way is a hindrance to the review process and this +should only be done to correct a DCO mistake. + +## Triggering CI re-run without making changes + +To rerun failed tasks in CI, add a comment with the the line + +``` +/retest +``` + +in it. This should rebuild only the failed tasks. + +Sometimes tasks will be stuck in CI and won't be marked as failed, which means +the above command won't work. Should this happen, pushing an empty commit should +re-run all the CI tasks. Consider adding an alias into your `.gitconfig` file: + +``` +[alias] + kick-ci = !"git commit -s --allow-empty -m 'Kick CI' && git push" +``` + +Once you add this alias you can issue the command `git kick-ci` and the PR +will be sent back for a retest. \ No newline at end of file diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 330a5f726..4c698e00d 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -1,10 +1,10 @@ # Maintainers -This document aims to assist maintainers. +This document aims to assist [maintainers](OWNERS.md). ## Pre-merge checklist -- Does the PR have breaking changes? Then that should be made explicit and mentioned on top in the [version history](docs/root/version_history.md). +- Does the PR have breaking changes? Then that should be explicitly mentioned in the [version history](docs/root/version_history.md). - New features should be added to the [version history](docs/root/version_history.md). - Breaking changes to the [proto apis](api/) are not allowed. diff --git a/OWNERS.md b/OWNERS.md new file mode 100644 index 000000000..6f0268609 --- /dev/null +++ b/OWNERS.md @@ -0,0 +1,12 @@ +* See [CONTRIBUTING.md](CONTRIBUTING.md) for general contribution guidelines. + +This page lists all active maintainers and their areas of expertise. This can be used for +routing PRs, questions, etc. to the right place. + +# Maintainers + +* Otto van der Schaaf ([oschaaf](https://github.com/oschaaf)) (oschaaf@we-amp.com) + * All things Nighthawk +* Harvey Tuch ([htuch](https://github.com/htuch)) (htuch@google.com) +* John Plevyak ([jplevyak](https://github.com/jplevyak)) (jplevyak@google.com) +* Jakub Sobon ([jplevyak](https://github.com/jplevyak)) (???@google.com) From 214a0374e68ee8d8b1d8d44756275fddc66eee02 Mon Sep 17 00:00:00 2001 From: Otto van der Schaaf Date: Mon, 16 Dec 2019 23:37:30 +0100 Subject: [PATCH 3/7] Review-feedback: Envoy domain expertise section Signed-off-by: Otto van der Schaaf --- MAINTAINERS.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 4c698e00d..397d7d2a3 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -2,6 +2,16 @@ This document aims to assist [maintainers](OWNERS.md). +## 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 internal computes cluster configuration, its +connection pool derivations, the `StreamDecoder` class, as well as anything related to the Nighthawk test server. + +See [OWNERS.md](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](docs/root/version_history.md). From 009ab22630c3896b2820ca46c3a2e098a7757a8d Mon Sep 17 00:00:00 2001 From: Otto van der Schaaf Date: Tue, 17 Dec 2019 10:34:13 +0100 Subject: [PATCH 4/7] Review feedback Signed-off-by: Otto van der Schaaf --- CONTRIBUTING.md | 145 ++---------------------------------------------- OWNERS.md | 4 +- 2 files changed, 7 insertions(+), 142 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index bb73c451a..4a9a2de6a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -18,157 +18,20 @@ Both API and implementation stability are important to Nighthawk. Since the API # Submitting a PR -* Fork the repo. -* Create your PR. -* Tests will automatically run for you. -* We will **not** merge any PR that is not passing tests. -* PRs are expected to have 100% test coverage for added code. This can be verified with a coverage - build. If your PR cannot have 100% coverage for some reason please clearly explain why when you - open it. +* Generally Nighthawk mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#pr-review-policy-for-maintainers) with respect to PR submission policy. * Any PR that changes user-facing behavior **must** have associated documentation in [docs](docs) as well as [release notes](docs/root/intro/version_history.rst). -* All code comments and documentation are expected to have proper English grammar and punctuation. - If you are not a fluent English speaker (or a bad writer ;-)) please let us know and we will try - to find some help but there are no guarantees. -* Your PR title should be descriptive, and generally start with a subsystem name followed by a - colon. Examples: - * "docs: fix grammar error" - * "http conn man: add new feature" -* Your PR description should have details on what the PR does. If it fixes an existing issue it - should end with "Fixes #XXX". -* When all of the tests are passing and all other conditions described herein are satisfied, a - maintainer will be assigned to review and merge the PR. -* Once you submit a PR, *please do not rebase it*. It's much easier to review if subsequent commits - are new commits and/or merges. We squash rebase the final merged commit so the number of commits - you have in the PR don't matter. -* We expect that once a PR is opened, it will be actively worked on until it is merged or closed. - We reserve the right to close PRs that are not making progress. This is generally defined as no - changes for 7 days. Obviously PRs that are closed due to lack of activity can be reopened later. - Closing stale PRs helps us to keep on top of all of the work currently in flight. # PR review policy for maintainers -* Typically we try to turn around reviews within one business day. +* Generally Nighthawk mirros [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#pr-review-policy-for-maintainers) with respect to maintainer review policy. * See [OWNERS.md](OWNERS.md) for the current list of maintainers. -* It is generally expected that a maintainer should review every PR. -* The above rules may be waived for PRs which only update docs or comments, or trivial changes to - tests and tools (where trivial is decided by the maintainer in question). -* If there is a question on who should review a PR please discuss in Slack. -* Anyone is welcome to review any PR that they want, whether they are a maintainer or not. -* Please **clean up the title and body** before merging. By default, GitHub fills the squash merge - title with the original title, and the commit body with every individual commit from the PR. - The maintainer doing the merge should make sure the title follows the guidelines above and should - overwrite the body with the original extended description from the PR (cleaning it up if necessary) - while preserving the PR author's final DCO sign-off. # DCO: Sign your work -Envoy ships commit hooks that allow you to auto-generate the DCO signoff line if -it doesn't exist when you run `git commit`. Simply navigate to the Envoy project -root and run: +Commits need to be signed off. [See here](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#dco-sign-your-work). -```bash -./support/bootstrap -``` - -From here, simply commit as normal, and you will see the signoff at the bottom -of each commit. - -The sign-off is a simple line at the end of the explanation for the -patch, which certifies that you wrote it or otherwise have the right to -pass it on as an open-source patch. The rules are pretty simple: if you -can certify the below (from -[developercertificate.org](https://developercertificate.org/)): - -``` -Developer Certificate of Origin -Version 1.1 - -Copyright (C) 2004, 2006 The Linux Foundation and its contributors. -660 York Street, Suite 102, -San Francisco, CA 94110 USA - -Everyone is permitted to copy and distribute verbatim copies of this -license document, but changing it is not allowed. - - -Developer's Certificate of Origin 1.1 - -By making a contribution to this project, I certify that: - -(a) The contribution was created in whole or in part by me and I - have the right to submit it under the open source license - indicated in the file; or - -(b) The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source - license and I have the right under that license to submit that - work with modifications, whether created in whole or in part - by me, under the same open source license (unless I am - permitted to submit under a different license), as indicated - in the file; or - -(c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. - -(d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. -``` - -then you just add a line to every git commit message: - - Signed-off-by: Joe Smith - -using your real name (sorry, no pseudonyms or anonymous contributions.) - -You can add the sign off when creating the git commit via `git commit -s`. - -If you want this to be automatic you can set up some aliases: - -```bash -git config --add alias.amend "commit -s --amend" -git config --add alias.c "commit -s" -``` - -## Fixing DCO - -If your PR fails the DCO check, it's necessary to fix the entire commit history in the PR. Best -practice is to [squash](https://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html) -the commit history to a single commit, append the DCO sign-off as described above, and [force -push](https://git-scm.com/docs/git-push#git-push---force). For example, if you have 2 commits in -your history: - -```bash -git rebase -i HEAD^^ -(interactive squash + DCO append) -git push origin -f -``` - -Note, that in general rewriting history in this way is a hindrance to the review process and this -should only be done to correct a DCO mistake. ## Triggering CI re-run without making changes -To rerun failed tasks in CI, add a comment with the the line - -``` -/retest -``` - -in it. This should rebuild only the failed tasks. - -Sometimes tasks will be stuck in CI and won't be marked as failed, which means -the above command won't work. Should this happen, pushing an empty commit should -re-run all the CI tasks. Consider adding an alias into your `.gitconfig` file: - -``` -[alias] - kick-ci = !"git commit -s --allow-empty -m 'Kick CI' && git push" -``` - -Once you add this alias you can issue the command `git kick-ci` and the PR -will be sent back for a retest. \ No newline at end of file +See [here](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#triggering-ci-re-run-without-making-changes). \ No newline at end of file diff --git a/OWNERS.md b/OWNERS.md index 6f0268609..cf69ef633 100644 --- a/OWNERS.md +++ b/OWNERS.md @@ -8,5 +8,7 @@ routing PRs, questions, etc. to the right place. * Otto van der Schaaf ([oschaaf](https://github.com/oschaaf)) (oschaaf@we-amp.com) * All things Nighthawk * Harvey Tuch ([htuch](https://github.com/htuch)) (htuch@google.com) + * Envoy internals, architecture and performance methodology. * John Plevyak ([jplevyak](https://github.com/jplevyak)) (jplevyak@google.com) -* Jakub Sobon ([jplevyak](https://github.com/jplevyak)) (???@google.com) + * Envoy internals and architecture. +* Jakub Sobon ([mum4k](https://github.com/mum4k)) (???@google.com) From 66ba23d986484432796788bbb5a155cf7f8c2a64 Mon Sep 17 00:00:00 2001 From: Otto van der Schaaf Date: Wed, 18 Dec 2019 09:37:45 +0100 Subject: [PATCH 5/7] Review feedback Signed-off-by: Otto van der Schaaf --- CONTRIBUTING.md | 8 +++----- MAINTAINERS.md | 8 ++++---- OWNERS.md | 3 ++- 3 files changed, 9 insertions(+), 10 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4a9a2de6a..a682ca8cc 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -3,9 +3,7 @@ maximize the chances of your PR being merged. # Communication -* Before starting work on a major feature, please reach out to us via GitHub, Slack, - email, etc. We will make sure no one else is already working on it and ask you to open a - GitHub issue. +* Before starting work on a major feature, please reach out to us via [GitHub](https://github.com/envoyproxy/nighthawk) or [Slack](https://envoyproxy.slack.com/archives/CDX3CGTT9). We will make sure no one else is already working on it and ask you to open a GitHub issue. * Small patches and bug fixes don't need prior communication. # Coding style @@ -18,9 +16,9 @@ Both API and implementation stability are important to Nighthawk. Since the API # Submitting a PR -* Generally Nighthawk mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#pr-review-policy-for-maintainers) with respect to PR submission policy. +* Generally Nighthawk mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#submitting-a-pr) with respect to PR submission policy. * Any PR that changes user-facing behavior **must** have associated documentation in [docs](docs) as - well as [release notes](docs/root/intro/version_history.rst). + well as [release notes](docs/root/version_history.rst). # PR review policy for maintainers diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 397d7d2a3..72b770479 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -20,9 +20,9 @@ Envoy internals. ## Updates to the Envoy dependency -We try to regularly synchronize our Envoy dependency with the latest revision. When we do so, that looks like: +We try to [regularly synchronize our Envoy dependency](https://github.com/envoyproxy/nighthawk/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+%22update+envoy%22+) 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](bazel/repositories.bzl) to update the commit and SHA. -- A sync of [.bazelrc](.bazelrc) -- A sync of the build image sha used in the [ci configuration](.circleci/config.yml). -- Any changes required to Nighthawk +- A sync of [.bazelrc](.bazelrc) with [Envoy's version](https://github.com/envoyproxy/envoy/blob/master/.bazelrc) to update our build configurations. +- A sync of the build image sha used in the [ci configuration](.circleci/config.yml) with [Envoy's version](https://github.com/envoyproxy/envoy/blob/master/.circleci/config.yml) 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. diff --git a/OWNERS.md b/OWNERS.md index cf69ef633..d53194152 100644 --- a/OWNERS.md +++ b/OWNERS.md @@ -11,4 +11,5 @@ routing PRs, questions, etc. to the right place. * Envoy internals, architecture and performance methodology. * John Plevyak ([jplevyak](https://github.com/jplevyak)) (jplevyak@google.com) * Envoy internals and architecture. -* Jakub Sobon ([mum4k](https://github.com/mum4k)) (???@google.com) +* Jakub Sobon ([mum4k](https://github.com/mum4k)) (mumak@google.com) + * APIs, general functionality and miscellany. From 7ff2dd22423b4c9e879b445c37fc507365c4bb94 Mon Sep 17 00:00:00 2001 From: Otto van der Schaaf Date: Thu, 19 Dec 2019 08:49:41 +0100 Subject: [PATCH 6/7] Review: fix nits Signed-off-by: Otto van der Schaaf --- CONTRIBUTING.md | 4 ++-- MAINTAINERS.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a682ca8cc..135027152 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -22,12 +22,12 @@ Both API and implementation stability are important to Nighthawk. Since the API # PR review policy for maintainers -* Generally Nighthawk mirros [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#pr-review-policy-for-maintainers) with respect to maintainer review policy. +* Generally Nighthawk mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#pr-review-policy-for-maintainers) with respect to maintainer review policy. * See [OWNERS.md](OWNERS.md) for the current list of maintainers. # DCO: Sign your work -Commits need to be signed off. [See here](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#dco-sign-your-work). +Commits need to be signed off. See [here](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#dco-sign-your-work). ## Triggering CI re-run without making changes diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 72b770479..f65bc06f3 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -6,7 +6,7 @@ This document aims to assist [maintainers](OWNERS.md). 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 internal computes cluster configuration, its +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](OWNERS.md) to find maintainers with expertise of @@ -16,7 +16,7 @@ Envoy internals. - Does the PR have breaking changes? Then that should be explicitly mentioned in the [version history](docs/root/version_history.md). - New features should be added to the [version history](docs/root/version_history.md). -- Breaking changes to the [proto apis](api/) are not allowed. +- Breaking changes to the [protobuf APIs](api/) are not allowed. ## Updates to the Envoy dependency From 63710cf9543cd470141e1317e2adda5e8bd8ba82 Mon Sep 17 00:00:00 2001 From: Otto van der Schaaf Date: Fri, 20 Dec 2019 08:35:18 +0100 Subject: [PATCH 7/7] Review: fix bad link, .rst -> .md Signed-off-by: Otto van der Schaaf --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 135027152..485881382 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -18,7 +18,7 @@ Both API and implementation stability are important to Nighthawk. Since the API * Generally Nighthawk mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#submitting-a-pr) with respect to PR submission policy. * Any PR that changes user-facing behavior **must** have associated documentation in [docs](docs) as - well as [release notes](docs/root/version_history.rst). + well as [release notes](docs/root/version_history.md). # PR review policy for maintainers