Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -90,7 +90,7 @@ maximize the chances of your PR being merged.
* 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 keep on top of all of the work currently in flight.
Closing stale PRs helps us to keep on top of all of the work currently in flight.
* If a commit deprecates a feature, the commit message must mention what has been deprecated.
Additionally, [DEPRECATED.md](DEPRECATED.md) must be updated as part of the commit.
* Please consider joining the [envoy-dev](https://groups.google.com/forum/#!forum/envoy-dev)
Expand Down
2 changes: 1 addition & 1 deletion REPO_LAYOUT.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ are:
## [source/](source/)

* [common/](source/common/): Core Envoy code (not specific to extensions) that is also not
specific to a standalone server implementation. I.e., this is code that could be used if Envoy
specific to a standalone server implementation. I.e., this is the code that could be used if Envoy
were eventually embedded as a library.
* [docs/](source/docs/): Miscellaneous developer/design documentation that is not relevant for
the public user documentation.
Expand Down
6 changes: 3 additions & 3 deletions SECURITY_RELEASE_PROCESS.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# Security Release Process

Envoy is a large growing community of volunteers, users, and vendors. The Envoy community has
adopted this security disclosures and response policy to ensure we responsibly handle critical
adopted this security disclosure and response policy to ensure we responsibly handle critical
issues.

## Product Security Team (PST)
Expand Down Expand Up @@ -73,7 +73,7 @@ These steps should be completed within the 1-7 days of Disclosure.
- The Fix Lead and the Fix Team will create a
[CVSS](https://www.first.org/cvss/specification-document) using the [CVSS
Calculator](https://www.first.org/cvss/calculator/3.0). The Fix Lead makes the final call on the
calculated CVSS; it is better to move quickly than make the CVSS perfect.
calculated CVSS; it is better to move quickly than making the CVSS perfect.
- The Fix Team will notify the Fix Lead that work on the fix branch is complete once there are LGTMs
on all commits in the private repo from one or more maintainers.

Expand Down Expand Up @@ -160,7 +160,7 @@ said issue, they must agree to the same terms and only find out information on a

In the unfortunate event you share the information beyond what is allowed by this policy, you _must_
urgently inform the envoy-security@googlegroups.com mailing list of exactly what information leaked
and to whom. A retrospective will take place after the leak so we can assess how to not make the
and to whom. A retrospective will take place after the leak so we can assess how to prevent making the
same mistake in the future.

If you continue to leak information and break the policy outlined here, you will be removed from the
Expand Down
4 changes: 2 additions & 2 deletions STYLE.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# C++ coding style

* The Envoy source code is formatted using clang-format. Thus all white space, etc.
* The Envoy source code is formatted using clang-format. Thus all white spaces, etc.
issues are taken care of automatically. The Travis tests will automatically check
the code format and fail. There are make targets that can both check the format
(check_format) as well as fix the code format for you (fix_format).
Expand Down Expand Up @@ -96,7 +96,7 @@ A few general notes on our error handling philosophy:
silently be ignored and should crash the process either via the C++ allocation error exception, an
explicit `RELEASE_ASSERT` following a third party library call, or an obvious crash on a subsequent
line via null pointer dereference. This rule is again based on the philosophy that the engineering
costs of properly handling these cases is not worth it. Time is better spent designing proper system
costs of properly handling these cases are not worth it. Time is better spent designing proper system
controls that shed load if resource usage becomes too high, etc.
* The "less is more" error handling philosophy described in the previous two points is primarily
based on the fact that restarts are designed to be fast, reliable and cheap.
Expand Down