Initial 1Password Operator commit

vendor/github.com/go-logr/logr/README.md

@@ -0,0 +1,36 @@
+# A more minimal logging API for Go
+
+Before you consider this package, please read [this blog post by the inimitable
+Dave Cheney](http://dave.cheney.net/2015/11/05/lets-talk-about-logging).  I
+really appreciate what he has to say, and it largely aligns with my own
+experiences.  Too many choices of levels means inconsistent logs.
+
+This package offers a purely abstract interface, based on these ideas but with
+a few twists.  Code can depend on just this interface and have the actual
+logging implementation be injected from callers.  Ideally only `main()` knows
+what logging implementation is being used.
+
+# Differences from Dave's ideas
+
+The main differences are:
+
+1) Dave basically proposes doing away with the notion of a logging API in favor
+of `fmt.Printf()`.  I disagree, especially when you consider things like output
+locations, timestamps, file and line decorations, and structured logging.  I
+restrict the API to just 2 types of logs: info and error.
+
+Info logs are things you want to tell the user which are not errors.  Error
+logs are, well, errors.  If your code receives an `error` from a subordinate
+function call and is logging that `error` *and not returning it*, use error
+logs.
+
+2) Verbosity-levels on info logs.  This gives developers a chance to indicate
+arbitrary grades of importance for info logs, without assigning names with
+semantic meaning such as "warning", "trace", and "debug".  Superficially this
+may feel very similar, but the primary difference is the lack of semantics.
+Because verbosity is a numerical value, it's safe to assume that an app running
+with higher verbosity means more (and less important) logs will be generated.
+
+This is a BETA grade API.  I have implemented it for
+[glog](https://godoc.org/github.com/golang/glog). Until there is a significant
+2nd implementation, I don't really know how it will change.