From eb7b52f95ad2af7378be8ca2ab3bbba8b1a00f34 Mon Sep 17 00:00:00 2001 From: George Kuan Date: Sun, 26 Apr 2015 19:37:14 -0700 Subject: [PATCH] Corrected some typos --- api_changes.md | 4 ++-- collab.md | 2 +- development.md | 2 +- faster_reviews.md | 6 +++--- logging.md | 2 +- profiling.md | 4 ++-- releasing.md | 2 +- writing-a-getting-started-guide.md | 8 ++++---- 8 files changed, 15 insertions(+), 15 deletions(-) diff --git a/api_changes.md b/api_changes.md index be02e16c1..6ab86ce0e 100644 --- a/api_changes.md +++ b/api_changes.md @@ -243,7 +243,7 @@ The fuzzer can be found in `pkg/api/testing/fuzzer.go`. ## Update the semantic comparisons VERY VERY rarely is this needed, but when it hits, it hurts. In some rare -cases we end up with objects (e.g. resource quantites) that have morally +cases we end up with objects (e.g. resource quantities) that have morally equivalent values with different bitwise representations (e.g. value 10 with a base-2 formatter is the same as value 0 with a base-10 formatter). The only way Go knows how to do deep-equality is through field-by-field bitwise comparisons. @@ -278,7 +278,7 @@ At last, your change is done, all unit tests pass, e2e passes, you're done, right? Actually, no. You just changed the API. If you are touching an existing facet of the API, you have to try *really* hard to make sure that *all* the examples and docs are updated. There's no easy way to do this, due -in part ot JSON and YAML silently dropping unknown fields. You're clever - +in part to JSON and YAML silently dropping unknown fields. You're clever - you'll figure it out. Put `grep` or `ack` to good use. If you added functionality, you should consider documenting it and/or writing diff --git a/collab.md b/collab.md index dd7b80590..000fb6ea5 100644 --- a/collab.md +++ b/collab.md @@ -29,7 +29,7 @@ Maintainers will do merges of appropriately reviewed-and-approved changes during There may be discussion an even approvals granted outside of the above hours, but merges will generally be deferred. If a PR is considered complex or controversial, the merge of that PR should be delayed to give all interested parties in all timezones the opportunity to provide feedback. Concretely, this means that such PRs should be held for 24 -hours before merging. Of course "complex" and "controversial" are left to the judgement of the people involved, but we trust that part of being a committer is the judgement required to evaluate such things honestly, and not be +hours before merging. Of course "complex" and "controversial" are left to the judgment of the people involved, but we trust that part of being a committer is the judgment required to evaluate such things honestly, and not be motivated by your desire (or your cube-mate's desire) to get their code merged. Also see "Holds" below, any reviewer can issue a "hold" to indicate that the PR is in fact complicated or complex and deserves further review. PRs that are incorrectly judged to be merge-able, may be reverted and subject to re-review, if subsequent reviewers believe that they in fact are controversial or complex. diff --git a/development.md b/development.md index bbd94fef7..556f7c225 100644 --- a/development.md +++ b/development.md @@ -221,7 +221,7 @@ go run hack/e2e.go -build -pushup -test -down # seeing the output of failed commands. # -ctl can be used to quickly call kubectl against your e2e cluster. Useful for -# cleaning up after a failed test or viewing logs. Use -v to avoid supressing +# cleaning up after a failed test or viewing logs. Use -v to avoid suppressing # kubectl output. go run hack/e2e.go -v -ctl='get events' go run hack/e2e.go -v -ctl='delete pod foobar' diff --git a/faster_reviews.md b/faster_reviews.md index a2d004657..2562879b2 100644 --- a/faster_reviews.md +++ b/faster_reviews.md @@ -135,7 +135,7 @@ might need later - but don't implement them now. We understand that it is hard to imagine, but sometimes we make mistakes. It's OK to push back on changes requested during a review. If you have a good reason -for doing something a certain way, you are absolutley allowed to debate the +for doing something a certain way, you are absolutely allowed to debate the merits of a requested change. You might be overruled, but you might also prevail. We're mostly pretty reasonable people. Mostly. @@ -151,7 +151,7 @@ things you can do that might help kick a stalled process along: * Ping the assignee (@username) on the PR comment stream asking for an estimate of when they can get to it. - * Ping the assigneed by email (many of us have email addresses that are well + * Ping the assignee by email (many of us have email addresses that are well published or are the same as our GitHub handle @google.com or @redhat.com). If you think you have fixed all the issues in a round of review, and you haven't @@ -171,7 +171,7 @@ explanation. ## Final: Use common sense Obviously, none of these points are hard rules. There is no document that can -take the place of common sense and good taste. Use your best judgement, but put +take the place of common sense and good taste. Use your best judgment, but put a bit of thought into how your work can be made easier to review. If you do these things your PRs will flow much more easily. diff --git a/logging.md b/logging.md index 82b6a0c8e..234304743 100644 --- a/logging.md +++ b/logging.md @@ -1,7 +1,7 @@ Logging Conventions =================== -The following conventions for the glog levels to use. [glog](http://godoc.org/github.com/golang/glog) is globally prefered to [log](http://golang.org/pkg/log/) for better runtime control. +The following conventions for the glog levels to use. [glog](http://godoc.org/github.com/golang/glog) is globally preferred to [log](http://golang.org/pkg/log/) for better runtime control. * glog.Errorf() - Always an error * glog.Warningf() - Something unexpected, but probably not an error diff --git a/profiling.md b/profiling.md index 1e14b5c47..03b17766c 100644 --- a/profiling.md +++ b/profiling.md @@ -4,7 +4,7 @@ This document explain how to plug in profiler and how to profile Kubernetes serv ## Profiling library -Go comes with inbuilt 'net/http/pprof' profiling library and profiling web service. The way service works is binding debug/pprof/ subtree on a running webserver to the profiler. Reading from subpages of debug/pprof returns pprof-formated profiles of the running binary. The output can be processed offline by the tool of choice, or used as an input to handy 'go tool pprof', which can graphically represent the result. +Go comes with inbuilt 'net/http/pprof' profiling library and profiling web service. The way service works is binding debug/pprof/ subtree on a running webserver to the profiler. Reading from subpages of debug/pprof returns pprof-formatted profiles of the running binary. The output can be processed offline by the tool of choice, or used as an input to handy 'go tool pprof', which can graphically represent the result. ## Adding profiling to services to APIserver. @@ -31,4 +31,4 @@ to get 30 sec. CPU profile. ## Contention profiling -To enable contetion profiling you need to add line ```rt.SetBlockProfileRate(1)``` in addition to ```m.mux.HandleFunc(...)``` added before (```rt``` stands for ```runtime``` in ```master.go```). This enables 'debug/pprof/block' subpage, which can be used as an input to ```go tool pprof```. +To enable contention profiling you need to add line ```rt.SetBlockProfileRate(1)``` in addition to ```m.mux.HandleFunc(...)``` added before (```rt``` stands for ```runtime``` in ```master.go```). This enables 'debug/pprof/block' subpage, which can be used as an input to ```go tool pprof```. diff --git a/releasing.md b/releasing.md index 125355c39..02bb0ca43 100644 --- a/releasing.md +++ b/releasing.md @@ -92,7 +92,7 @@ get` while in fact they do not match `v0.5` (the one that was tagged) exactly. To handle that case, creating a new release should involve creating two adjacent commits where the first of them will set the version to `v0.5` and the second will set it to `v0.5-dev`. In that case, even in the presence of merges, there -will be a single comit where the exact `v0.5` version will be used and all +will be a single commit where the exact `v0.5` version will be used and all others around it will either have `v0.4-dev` or `v0.5-dev`. The diagram below illustrates it. diff --git a/writing-a-getting-started-guide.md b/writing-a-getting-started-guide.md index 7c837351f..c1066f06d 100644 --- a/writing-a-getting-started-guide.md +++ b/writing-a-getting-started-guide.md @@ -6,7 +6,7 @@ guide. A Getting Started Guide is instructions on how to create a Kubernetes cluster on top of a particular type(s) of infrastructure. Infrastructure includes: the IaaS provider for VMs; the node OS; inter-node networking; and node Configuration Management system. -A guide refers to scripts, Configuration Manangement files, and/or binary assets such as RPMs. We call +A guide refers to scripts, Configuration Management files, and/or binary assets such as RPMs. We call the combination of all these things needed to run on a particular type of infrastructure a **distro**. @@ -39,7 +39,7 @@ These guidelines say *what* to do. See the Rationale section for *why*. that are updated to the new version. - Versioned distros should typically not modify or add code in `cluster/`. That is just scripts for developer distros. - - If a versioned distro has not been updated for many binary releases, it may be dropped frome the Matrix. + - If a versioned distro has not been updated for many binary releases, it may be dropped from the Matrix. If you have a cluster partially working, but doing all the above steps seems like too much work, we still want to hear from you. We suggest you write a blog post or a Gist, and we will link to it on our wiki page. @@ -58,13 +58,13 @@ These guidelines say *what* to do. See the Rationale section for *why*. - a development distro needs to have an organization which owns it. This organization needs to: - Setting up and maintaining Continuous Integration that runs e2e frequently (multiple times per day) against the Distro at head, and which notifies all devs of breakage. - - being reasonably available for questions and assiting with + - being reasonably available for questions and assisting with refactoring and feature additions that affect code for their IaaS. ## Rationale - We want want people to create Kubernetes clusters with whatever IaaS, Node OS, configuration management tools, and so on, which they are familiar with. The - guidelines for **versioned distros** are designed for flexiblity. + guidelines for **versioned distros** are designed for flexibility. - We want developers to be able to work without understanding all the permutations of IaaS, NodeOS, and configuration management. The guidelines for **developer distros** are designed for consistency.