diff --git a/AUTHORS b/AUTHORS deleted file mode 100644 index 7b2bbee6f..000000000 --- a/AUTHORS +++ /dev/null @@ -1,13 +0,0 @@ -# This is the official list of KubeSphere authors for copyright purposes. -# This file is distinct from the CONTRIBUTORS files. -# See the latter for an explanation. - -# Names should be added to this file as one of -# Organization's name -# Individual's name -# Individual's name -# See CONTRIBUTORS for the meaning of multiple email addresses. - -# Please keep the list sorted. - -Yunify Inc. diff --git a/CONTRIBUTORS b/CONTRIBUTORS deleted file mode 100644 index f32a492a2..000000000 --- a/CONTRIBUTORS +++ /dev/null @@ -1,20 +0,0 @@ -# This is the official list of people who can contribute -# (and typically have contributed) code to the KubeSphere repository. -# The AUTHORS file lists the copyright holders; this file -# lists people. For example, Yunify employees are listed here -# but not in AUTHORS, because Yunify holds the copyright. -# -# When adding J Random Contributor's name to this file, -# either J's name or J's organization's name should be -# added to the AUTHORS file. - -# Names should be added to this file like so: -# Individual's name -# Individual's name -# -# An entry with multiple email addresses specifies that the -# first address should be used in the submit logs. - -# Please keep the list sorted. - -Ray@qingcloud \ No newline at end of file diff --git a/README.md b/README.md index 0ad3bd3c8..1cbac16af 100644 --- a/README.md +++ b/README.md @@ -8,20 +8,19 @@ **Features:** - Multiple IaaS platform support, including baremetal/KVM/QingCloud, and more will be supported in future release. - Easy setup of Kubernetes standalone(only one master node) and cluster environment(including High Availability support). - - Powerful management console to help business users to manage and monitor the Kubernetes environment. + - Powerful management console to help business users to manage and monitor the Kubernetes. - Integrate with [OpenPitrix](https://github.com/openpitrix) to provide full life cycle of application management and be compatible of helm package. - Support popular open source network solutions, including calico and flannel, also could use [qingcloud hostnic solution](https://github.com/yunify/hostnic-cni) if the Kubernetes is deployed on QingCloud platform. - - Support popular open source storage solutions, including Glusterfs and Cephfs, also could use [qingcloud storage solution](https://github.com/yunify/qingcloud-volume-provisioner) if the Kubernetes is deployed on QingCloud platform. + - Support popular open source storage solutions, including Glusterfs and Cephfs, also could use [qingcloud storage solution](https://github.com/yunify/qingcloud-csi) or [qingstor storage solution](https://github.com/yunify/qingstor-csi) if the Kubernetes is deployed on QingCloud platform or QingStor NeonSAN. - CI/CD support. - Service Mesh support. - Multiple image registries support. - - Federation support. - Integrate with QingCloud IAM. ---- ## Motivation -The project originates from the requirement and pains we heard from our customers on public and private QingCloud platform, who have strong will to deploy Kubernetes in their IT system but struggle on completed setup process and long learning curve. With help of KubeSphere, their IT operators could setup Kubernetes environment quickly and use an easy management UI interface to mange their applications. +The project originates from the requirement and pains we heard from our customers on public and private QingCloud platform, who have strong will to deploy Kubernetes in their IT system but struggle on completed setup process and long learning curve. With help of KubeSphere, their IT operators could setup Kubernetes environment quickly and use an easy management UI interface to mange their applications, also KubeSphere provides more features to help customers to handle daily business more easily, including CI/CD, micro services management...etc. Getting Started --------------- @@ -31,8 +30,8 @@ Getting Started ## Contributing to the project -All [members](docs/members.md) of the KubeSphere community must abide by [Code of Conduct](code-of-conduct.md). Only by respecting each other can we develop a productive, collaborative community. +All members of the KubeSphere community must abide by [Code of Conduct](docs/code-of-conduct.md). Only by respecting each other can we develop a productive, collaborative community. -You can then check out how to [setup for development](docs/development.md). +You can then find out more detail [here](docs/welcome-toKubeSphere-new-developer-guide.md). diff --git a/docs/README.md b/docs/README.md deleted file mode 100644 index 82f591aa3..000000000 --- a/docs/README.md +++ /dev/null @@ -1,51 +0,0 @@ -# OpenPitrix Developer Guide - -The developer guide is for anyone wanting to either write code which directly accesses the -OpenPitrix API, or to contribute directly to the OpenPitrix project. - - -## The process of developing and contributing code to the OpenPitrix project - -* **Welcome to OpenPitrix (New Developer Guide)** - ([welcome-to-OpenPitrix-new-developer-guide.md](welcome-to-OpenPitrix-new-developer-guide.md)): - An introductory guide to contributing to OpenPitrix. - -* **On Collaborative Development** ([collab.md](collab.md)): Info on pull requests and code reviews. - -* **GitHub Issues** ([issues.md](issues.md)): How incoming issues are triaged. - -* **Pull Request Process** ([pull-requests.md](pull-requests.md)): When and why pull requests are closed. - -* **Getting Recent Builds** ([getting-builds.md](getting-builds.md)): How to get recent builds including the latest builds that pass CI. - -* **Automated Tools** ([automation.md](automation.md)): Descriptions of the automation that is running on our github repository. - - -## Setting up your dev environment, coding, and debugging - -* **Development Guide** ([development.md](development.md)): Setting up your development environment. - -* **Testing** ([testing.md](testing.md)): How to run unit, integration, and end-to-end tests in your development sandbox. - -* **Hunting flaky tests** ([flaky-tests.md](flaky-tests.md)): We have a goal of 99.9% flake free tests. - Here's how to run your tests many times. - -* **Logging Conventions** ([logging.md](logging.md)): Glog levels. - -* **Coding Conventions** ([coding-conventions.md](coding-conventions.md)): - Coding style advice for contributors. - -* **Document Conventions** ([how-to-doc.md](how-to-doc.md)) - Document style advice for contributors. - -* **Running a cluster locally** ([running-locally.md](running-locally.md)): - A fast and lightweight local cluster deployment for development. - -## Developing against the OpenPitrix API - -* The [REST API documentation](http://openpitrix.io/docs/reference/) explains the REST - API exposed by apiserver. - -## Building releases - -See the [openpitrix/release](https://github.com/kubernetes/release) repository for details on creating releases and related tools and helper scripts. diff --git a/code-of-conduct.md b/docs/code-of-conduct.md similarity index 100% rename from code-of-conduct.md rename to docs/code-of-conduct.md diff --git a/docs/development.md b/docs/development.md deleted file mode 100644 index 47b759b6e..000000000 --- a/docs/development.md +++ /dev/null @@ -1,74 +0,0 @@ -# Developing for KubeSphere - -The [community repository](https://github.com/kubesphere) hosts all information about -building KubeSphere from source, how to contribute code and documentation, who to contact about what, etc. If you find a requirement that this doc does not capture, or if you find other docs with references to requirements that are not simply links to this doc, please [submit an issue](https://github.com/kubesphere/kubesphere/issues/new). - ----- - -## To start developing KubeSphere - -First of all, you should fork the project. Then follow one of the three options below to develop the project. Please note you should replace the official repo when using __go get__ or __git clone__ below with your own one. - -### 1. You have a working [Docker Compose](https://docs.docker.com/compose/install) environment [recommend]. ->You need to install [Docker](https://docs.docker.com/engine/installation/) first. - -```shell -$ git clone https://github.com/kubesphere/kubesphere -$ cd kubesphere -$ make build -$ make compose-up -``` - -Exit docker runtime environment -```shell -$ make compose-down -``` - -### 2. You have a working [Docker](https://docs.docker.com/engine/installation/) environment. - - -Exit docker runtime environment -```shell -$ docker stop $(docker ps -f name=kubesphere -q) -``` - -### 3. You have a working [Go](prereqs.md#setting-up-go) environment. - -- Install [protoc compiler](https://github.com/google/protobuf/releases/) -- Install protoc plugin: - -```shell -$ go get github.com/golang/protobuf/protoc-gen-go -$ go get github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway -$ go get github.com/grpc-ecosystem/grpc-gateway/protoc-gen-swagger -$ go get github.com/mwitkow/go-proto-validators/protoc-gen-govalidators -``` - -- Get kubesphere source code and build service: - -```shell -$ go get -d kubesphere.io/kubesphere -$ cd $GOPATH/src/kubesphere.io/kubesphere -$ make generate -$ GOBIN=`pwd`/bin go install ./cmd/... -``` - -- Start KubeSphere service: - - -- Exit go runtime environment -```shell -$ ps aux | grep kubesphere- | grep -v grep | awk '{print $2}' | xargs kill -9 -``` - ----- - -## Test KubeSphere - -Visit http://127.0.0.1:9100/swagger-ui in browser, and try it online, or test kubesphere api service via command line: - ----- - -## DevOps - -Please check [How to set up DevOps environment](devops.md). diff --git a/docs/devops.md b/docs/devops.md deleted file mode 100644 index 069a8fe12..000000000 --- a/docs/devops.md +++ /dev/null @@ -1,79 +0,0 @@ -# Set Up DevOps Environment - -DevOps is recommended to use for this project. Please follow the instructions below to set up your environment. We use Jenkins with Blue Ocean plugin and deploy it on Kubernetes, also continuously deploy KubeSphere on the Kubernetes cluster. - ----- - -- [Create Kubernetes Cluster](#create-kubernetes-cluster) -- [Deploy Jenkins](#deploy-jenkins) -- [Configure Jenkins](#configure-jenkins) -- [Create a Pipeline](#create-a-pipeline) - -## Create Kubernetes Cluster - -We are using [Kubernetes on QingCloud](https://appcenter.qingcloud.com/apps/app-u0llx5j8) to create a kubernetes production environment by one click. Please follow the [instructions](https://appcenter-docs.qingcloud.com/user-guide/apps/docs/kubernetes/) to create your own cluster. Access the Kubernetes client using one of the following options. - - **Open VPN**: Go to the left navigation tree of the [QingCloud console](https://console.qingcloud.com), choose _Networks & CDN_, then _VPC Networks_; on the content of the VPC page, choose _Management Configuration_, _VPN Service_, then you will find _Open VPN_ service. Here is the [screenshot](images/openvpn.png) of the page. - - **Port Forwarding**: same as Open VPN, but choose _Port Forwarding_ on the content of VPC page instead of VPN Service; and add a rule to forward source port to the port of ssh port of the kubernetes client, for instance, forward 10007 to 22 of the kubernetes client with the private IP being 192.168.100.7. After that, you need to open the firewall to allow the port 10007 accessible from outside. Please click the _Security Group_ ID on the same page of the VPC, and add the downstream rule for the firewall. - - **VNC**: If you don't want to access the client node remotely, just go to the kubernetes cluster detailed page on the [QingCloud console](https://console.qingcloud.com), and click the windows icon aside of the client ID shown as the [screenshot](images/kubernets.png) (user/password: root/k8s). The way is not recommended, however you can check kubernetes quickly using VNC since you don't configure anything. - -## Deploy Jenkins - -1. Copy the [yaml file](../devops/kubernetes/jenkins-qingcloud.yaml) to the kubernetes client, and deploy - ``` - # kubectl apply -f jenkins-qingcloud.yaml - ``` - -2. Access Jenkins console by opening http://\:9200 where ip depends on how you expose the Jenkins service to outside explained below. (You can find your way to access Jenkins console such as ingress, cloud LB etc.) On the kubernetes client - ``` - # iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 9200 -j DNAT --to-destination "$(kubectl get svc -n jenkins --selector=app=jenkins -o jsonpath='{.items..spec.clusterIP}')":9200 - # iptables -t nat -A POSTROUTING -p tcp --dport 9200 -j MASQUERADE - # sysctl -w net.ipv4.conf.eth0.route_localnet=1 - ``` - -3. Now the request to the kubernetes client port 9200 will be forwarded to the Jenkins service. - - - If you use [Open VPN](#openvpn) to access the kubernetes client, then open http://\:9200 to access Jenkins console. - - If you use [Port Forwarding](#port-forwarding) to access the client, then forward the VPC port 9200 to the kubernetes client port 9200. Now open http://\:9200 to access Jenkins console. - -## Configure Jenkins - > You can refer [jenkins.io](https://jenkins.io/doc/tutorials/using-jenkins-to-build-a-java-maven-project/) about how to configure Jenkins and create a pipeline. - -1. Unlock Jenkins - - - Get the Adminstrator password from the log on the kubernetes client - ``` - # kubectl logs "$(kubectl get pods -n jenkins --selector=app=jenkins -o jsonpath='{.items..metadata.name}')" -c jenkins -n jenkins - ``` - - Go to Jenkins console, paste the password and continue. Install suggested plugins, then create the first admin user and save & finish. - -2. Configure Jenkins - - We will deploy KubeSphere application into the same Kubernetes cluster as the one that the Jenkins is running on. So we need configure the Jenkins pod to access the Kubernetes cluster, and log in docker registry given that during the [Jenkins pipeline](#create-a-pipeline) we push KubeSphere image into a registry which you can change on your own. - - On the Kubernetes client, execute the following to log in Jenkins container. - - ``` - # kubectl exec -it "$(kubectl get pods -n jenkins --selector=app=jenkins -o jsonpath='{.items..metadata.name}')" -c jenkins -n jenkins -- /bin/bash - ``` - - After logging in the Jenkins container, then run the following to log in docker registry and prepare folder to hold kubectl configuration. - - ``` - bash-4.3# docker login -u xxx -p xxxx - bash-4.3# mkdir /root/.kube - bash-4.3# exit - ``` - - Once back again to the Kubernetes client, run the following to copy the tool kubectl and its configuration from the client to the Jenkins container. - - ``` - # kubectl cp /usr/bin/kubectl jenkins/"$(kubectl get pods -n jenkins --selector=app=jenkins -o jsonpath='{.items..metadata.name}')":/usr/bin/kubectl -c jenkins - # kubectl cp /root/.kube/config jenkins/"$(kubectl get pods -n jenkins --selector=app=jenkins -o jsonpath='{.items..metadata.name}')":/root/.kube/config -c jenkins - ``` - -## Create a pipeline - - Fork KubeSphere from github for your development. You need to change the docker repository to your own in the files [kubesphere.yaml](devops/kubernetes/kubesphere.yaml), [build-images.sh](devops/scripts/build-images.sh), [push-images.sh](devops/scripts/push-images.sh) and [clean.sh](devops/scripts/clean.sh). - - On the Jenkins panel, click _Open Blue Ocean_ and start to create a new pipeline. Choose _GitHub_, paste your access key of GitHub, select the repository you want to create a CI/CD pipeline. We already created the pipeline Jenkinsfile on the upstream repository which includes compiling KubeSphere, building images, push images, deploying the application, verifying the application and cleaning up. - - It is better to configure one more thing. On the Jenkins panel, go to the configuration of KubeSphere, check _Periodically if not otherwise run_ under _Scan Repository Triggers_ and select the interval at your will. - - If your repository is an upstream, you can select _Discover pull requests from forks_ under _Behaviors_ so that the pipeline will work for PR before merged. - - Now it is good to go. Whenever you commit a change to your forked repository, the pipeline will work during the Jenkins trigger interval. diff --git a/docs/members.md b/docs/members.md deleted file mode 100644 index 83d6f708b..000000000 --- a/docs/members.md +++ /dev/null @@ -1,12 +0,0 @@ -# Contributors - -## Component and Member List - -| Name | Leads | -|------|-------| -| Deployment | (yunify) | -| Service | (yunify) | -| Application | (yunify) | -| Cluster | Jeff (yunify) | -| App Runtime | (yunify) | -| Documents | | diff --git a/docs/modules/app-manager/README.md b/docs/modules/app-manager/README.md deleted file mode 100644 index c13c13080..000000000 --- a/docs/modules/app-manager/README.md +++ /dev/null @@ -1,22 +0,0 @@ -## QuickStart -KubeSphere uses same app-manager module from [OpenPitrix](https://github/openpitrix/openpitrix), which is another open source project initiated by QingCloud. -For testing and development purpose, follow steps below to setup app-manager service locally: -* Make sure git and docker runtime is installed in your local environment -* Clone the OpenPitrix project to your local environment: - ```console - git clone https://github.com/openpitrix/openpitrix.git - ``` -* Get into openpitrix directory, run commands below: - ```console - cd openpitrix - make build - make compose-up-app - ``` - -## Test app-manager - -Visit http://127.0.0.1:9100/swagger-ui in browser, and try it online, or test app-manager api service via command line: - -```shell -$ curl http://localhost:9100/v1/apps -{"total_items":0,"total_pages":0,"page_size":10,"current_page":1} \ No newline at end of file diff --git a/docs/prereqs.md b/docs/prereqs.md index ddcfb3412..6a814cd6f 100644 --- a/docs/prereqs.md +++ b/docs/prereqs.md @@ -12,7 +12,6 @@ branch, but release branches should not change. - [Prerequisites](#prerequisites) - [Setting up Go](#setting-up-go) - - [Setting up Swagger](#setting-up-swagger) - [To start developing KubeSphere](#to-start-developing-kubesphere) - [DevOps](#devops) @@ -37,20 +36,6 @@ $ export GOPATH=~/go $ export PATH=$PATH:$GOPATH/bin ``` -### Setting up Swagger - -KubeSphere is using [OpenAPI/Swagger](https://swagger.io) to develop API, so follow -[the instructions](https://github.com/go-swagger/go-swagger/tree/master/docs) to -install Swagger. If you are not familar with Swagger, please read the -[tutorial](http://apihandyman.io/writing-openapi-swagger-specification-tutorial-part-1-introduction/#writing-openapi-fka-swagger-specification-tutorial). If you install Swagger using docker distribution, -please run - -```shell -$ docker pull quay.io/goswagger/swagger -$ alias swagger="docker run --rm -it -e GOPATH=$GOPATH:/go -v $HOME:$HOME -w $(pwd) quay.io/goswagger/swagger" -$ swagger version -``` - ## To start developing KubeSphere There are two options to get KubeSphere source code and build the project: @@ -70,7 +55,3 @@ $ git clone https://github.com/kubesphere/kubesphere $ cd kubesphere $ make ``` - -## DevOps - -Please check [How to set up DevOps environment](devops.md) diff --git a/docs/pull-requests.md b/docs/pull-requests.md index b55d294d2..4baf9402e 100644 --- a/docs/pull-requests.md +++ b/docs/pull-requests.md @@ -4,7 +4,6 @@ This doc explains the process and best practices for submitting a PR to the [Kub - [Before You Submit a PR](#before-you-submit-a-pr) * [Run Local Verifications](#run-local-verifications) - * [Sign the CLA](#sign-the-cla) - [The PR Submit Process](#the-pr-submit-process) * [Write Release Notes if Needed](#write-release-notes-if-needed) * [The Testing and Merge Workflow](#the-testing-and-merge-workflow) @@ -38,22 +37,10 @@ This guide is for contributors who already have a PR to submit. If you're lookin You can run these local verifications before you submit your PR to predict the pass or fail of continuous integration. -* Run and pass `make verify` (can take 30-40 minutes) -* Run and pass `make test` -* Run and pass `make test-integration` - -## Sign the CLA - -You must sign the CLA before your first contribution. [Read more about the CLA.](https://github.com/kubesphere/kubesphere/docs/CLA.md) - -If you haven't signed the Contributor License Agreement (CLA) before making a PR, -the `@o8x-ci-robot` will leave a comment with instructions on how to sign the CLA. - # The PR Submit Process Merging a PR requires the following steps to be completed before the PR will be merged automatically. For details about each step, see the [The Testing and Merge Workflow](#the-testing-and-merge-workflow) section below. -- Sign the CLA (prerequisite) - Make the PR - Release notes - do one of the following: - Add notes in the release notes block, or @@ -152,15 +139,15 @@ If you want to solicit reviews before the implementation of your pull request is The GitHub robots will add and remove the `do-not-merge/hold` label as you use the comment commands and the `do-not-merge/work-in-progress` label as you edit your title. While either label is present, your pull request will not be considered for merging. -## Comment Commands Reference +## Comment Commands Reference//TODO [The commands doc]() contains a reference for all comment commands. //TODO -## Automation +## Automation//TODO The KubeSphere developer community uses a variety of automation to manage pull requests. This automation is described in detail [in the automation doc](automation.md). //TODO -## How the Tests Work +## How the Tests Work//TODO The tests will post the status results to the PR. If an e2e test fails, `@o8x-ci-robot` will comment on the PR with the test history and the @@ -212,7 +199,7 @@ Let's talk about best practices so your PR gets reviewed quickly. ## 0. Familiarize yourself with project conventions -* [Development guide](development.md) +* [Development guide](code-of-conduct.md) ## 1. Is the feature wanted? Make a Design Doc or Sketch PR @@ -220,7 +207,7 @@ Are you sure Feature-X is something the KubeSphere team wants or will accept? Is It's better to get confirmation beforehand. There are two ways to do this: -- Make a proposal doc (in docs/proposals; for example [the QoS proposal](), or reach out to the affected special interest group (SIG). Here's a [list of SIGs](https://github.com/KubeSphere/KubeSphere/docs/sig-list.md) +- Make a proposal doc (in docs/proposals; for example [the QoS proposal]() - Coordinate your effort with [SIG Docs]() ahead of time. //TODO - Make a sketch PR (e.g., just the API or Go interface). Write or code up just enough to express the idea and the design and why you made those choices diff --git a/docs/welcome-to-KubeSphere-new-developer-guide.md b/docs/welcome-to-KubeSphere-new-developer-guide.md index 6ca41b9eb..234c18c18 100644 --- a/docs/welcome-to-KubeSphere-new-developer-guide.md +++ b/docs/welcome-to-KubeSphere-new-developer-guide.md @@ -2,57 +2,30 @@ Welcome to KubeSphere! (New Developer Guide) ============================================ -_This document assumes that you know what KubeSphere does. If you don't, -try the demo at [https://o8x.io/](https://kubesphere.io/)._ +_This document assumes that you know what KubeSphere does. Introduction ------------ -Have you ever wanted to contribute to the coolest cloud technology? This +This document will help you understand the organization of the KubeSphere project and direct you to the best places to get started. By the end of this doc, you'll be able to pick up issues, write code to fix them, and get your work reviewed and merged. If you have questions about the development process, feel free to jump into our -[Slack workspace](http://KubeSphere.slack.com/) or join our [mailing -list](https://groups.google.com/forum/#!forum/KubeSphere-dev). If you join the +[Slack workspace](http://KubeSphere.slack.com/). If you join the Slack workspace it is recommended to set your Slack display name to your GitHub account handle. -Special Interest Groups ------------------------ -KubeSphere developers work in teams called Special Interest Groups (SIGs). At -the time of this writing there are [2 SIGs](sig-list.md). - -The developers within each SIG have autonomy and ownership over that SIG's part -of KubeSphere. SIGs organize themselves by meeting regularly and submitting -markdown design documents to the -[KubeSphere/community](https://github.com/KubeSphere/community) repository. -Like everything else in KubeSphere, a SIG is an open, community, effort. Anybody -is welcome to jump into a SIG and begin fixing issues, critiquing design -proposals and reviewing code. - -Most people who visit the KubeSphere repository for the first time are -bewildered by the thousands of [open -issues](https://github.com/KubeSphere/KubeSphere/issues) in our main repository. -But now that you know about SIGs, it's easy to filter by labels to see what's -going on in a particular SIG. For more information about our issue system, check -out -[issues.md](https://github.com/KubeSphere/community/blob/master/contributors/devel/issues.md). - -//TODO Downloading, Building, and Testing KubeSphere --------------------------------------------- This guide is non-technical, so it does not cover the technical details of working KubeSphere. We have plenty of documentation available under -[github.com/KubeSphere/KubeSphere/docs/](https://github.com/KubeSphere/KubeSphere/docs/). -Check out -[development.md](https://github.com/KubeSphere/KubeSphere/docs/development.md) -for more details. +[docs.kubesphere.io](https://docs.kubesphere.io). Pull-Request Process -------------------- @@ -61,21 +34,4 @@ The pull-request process is documented in [pull-requests.md](pull-requests.md). As described in that document, you must sign the CLA before KubeSphere can accept your contribution. - -The Release Process and Code Freeze ------------------------------------ - -Every so often @o8x-merge-robot will refuse to merge your PR, saying something -about release milestones. This happens when we are in a code freeze for a -release. In order to ensure KubeSphere is stable, we stop merging everything -that's not a bugfix, then focus on making all the release tests pass. This code -freeze usually lasts two weeks and happens once per quarter. - -If you're new to KubeSphere, you won't have to worry about this too much. After -you've contributed for a few months, you will be added as a [community -member](https://github.com/KubeSphere/KubeSphere/docs/membership.md) -and take ownership of some of the tests. At this point, you'll work with members -of your SIG to review PRs coming into your area and track down issues that occur -in tests. - Thanks for reading!