An approver/reviewer in @kubernetes, may sponsor someone for the
kubernetes org or any of the related organizations
(kubernetes-sigs, kubernetes-csi etc); as long as it's a project
they're involved with.
However, this does not work the other way around.
A sponsor that is only an approver/reviewer in kubernetes-sigs cannot
sponsor someone for membership in the kubernetes org.
They are scoped just to the org they're associated with.
It's confusing having two links for the release-engineering subproject
without any description of each. The k/release repo houses all of the
existing tooling, such as anago, while the k/sig-release repo houses the
procedures and processes. Add these links explicitly to the description
so that newcomers have a clearer idea of where to get started.
The default python on my system is python3. This caused me to run into
https://github.com/bazelbuild/rules_docker/issues/454 when running
`bazel build //...`. Update the documentation to indicate that
`/usr/bin/env python` must resolve to python2 in order for all of the
Bazel commands included in the documentation to work.
We can remove this comment after Bazel better supports using python3 as
the default system python. It appears from
https://github.com/bazelbuild/rules_docker/issues/580 that the
`rules_docker` folks hope to merge the fix in mid to late Q1 2019.
Previously, information on running unit and integration tests lived in
the testing.md doc, while information on running e2e tests lived in its
own doc. The testing.md doc is getting large, and particularly since its
a doc that many new members of the project look at, I think there's a
lot of benefit to keeping it concise.
To accomplish this, move information around running integration tests
into integration-tests.md, and then link to said document from
testing.md. This allows a new member of the project to get up and
running with unit tests, and then explore integration/e2e testing as
they have the need.
Improve the testing documentation in the following ways:
1. Ensure all of the given commands actually work. Some of them
specified tests that no longer existed or packages that no longer had
tests.
2. Clarify the ability to run tests for a package and all its
subpackages with `/...`.
3. Clarify how the developer can also utilize `go test` if they desire.
Brian Grant
Kubernetes Prow Robot
Michael Michael
Nikhita Raghunath
James Munnelly
Benjamin Elder
Craig Peters
Linus Arver
Ihor Dvoretskyi
Aaron Crickenberger
mattjmcnaughton
destijl
Fabian Baier
Craig Ingram
Jorge O. Castro
eduartua