Skip to content

Maintainers + Governance + Security docs #671

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Oct 26, 2021
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
6 changes: 3 additions & 3 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,9 @@ process. To contribute a PR, fork this project, create a new branch, make
changes on that branch, and then use GitHub to open a pull request with your
changes.

Every PR must be reviewed by at least one [Core Maintainer](https://github.com/orgs/kube-rs/teams/core-maintainers) of the project. Once
a PR has been marked "Approved" by a Core Maintainer (and no other core
maintainer has an open "Rejected" vote), the PR may be merged. While it is fine
Every PR must be reviewed by at least one [Maintainer](./maintainers.md) of the project. Once
a PR has been marked "Approved" by a Maintainer (and no other
Maintainer has an open "Rejected" vote), the PR may be merged. While it is fine
for non-maintainers to contribute their own code reviews, those reviews do not
satisfy the above requirement.

Expand Down
25 changes: 25 additions & 0 deletions SECURITY.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Security Policy

## Supported Versions

We provide security updates for the two most recent minor versions released on `crates.io`.

For example, if `0.70.1` is the most recent stable version, we will address security updates for `0.69` and later.
Once `0.71.1` is released, we will no longer provide updates for `0.69` releases.
Comment on lines +5 to +8
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense for now. We'll probably want to revisit this around the 1.0 release.


## Reporting a Vulnerability

To report a security problem in Kube-rs, please contact at least two [maintainers][./maintainers.md]

These people will help diagnose the severity of the issue and determine how to address the issue.
Issues deemed to be non-critical will be filed as GitHub issues.
Critical issues will receive immediate attention and be fixed as quickly as possible.

## Security Advisories

When serious security problems in Kube-rs are discovered and corrected, we issue a security advisory, describing the problem and containing a pointer to the fix.

These are announced the [RustSec Advisory Database](https://github.com/rustsec/advisory-db), to our github issues under the label `critical`, as well as discord and other primary communication channels.

Security issues are fixed as soon as possible, and the fixes are propagated to the stable branches as fast as possible. However, when a vulnerability is found during a code audit, or when several other issues are likely to be spotted and fixed in the near future, the security team may delay the release of a Security Advisory, so that one unique, comprehensive Security Advisory covering several vulnerabilities can be issued.
Communication with vendors and other distributions shipping the same code may also cause these delays.
55 changes: 55 additions & 0 deletions governance.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# Kube-rs Governance

This document defines project governance for Kube-rs.

## Contributors

Kube-rs is for everyone. Anyone can become a Kube-rs contributor simply by contributing to the project, whether through code, documentation, blog posts, community management, or other means.
As with all Kube-rs community members, contributors are expected to follow the [Kube-rs Code of Conduct][coc].

All contributions to Kube-rs code, documentation, or other components in the Kube-rs GitHub org must follow the guidelines in [CONTRIBUTING.md][contrib].
Whether these contributions are merged into the project is the prerogative of the maintainers.

## Maintainer Expectations

Maintainers have the ability to merge code into the project. Anyone can become a Kube-rs maintainer (see "Becoming a maintainer" below.)

As such, there are certain expectations for maintainers. Kube-rs maintainers are expected to:

* Review pull requests, triage issues, and fix bugs in their areas of expertise, ensuring that all changes go through the project's code review and integration processes.
* Monitor the Kube-rs Discord, and Discussions and help out when possible.
* Rapidly respond to any time-sensitive security release processes.
* Participate on discussions on the roadmap.

If a maintainer is no longer interested in or cannot perform the duties listed above, they should move themselves to emeritus status.
If necessary, this can also occur through the decision-making process outlined below.

### Maintainer decision-making

Ideally, all project decisions are resolved by maintainer consensus.
If this is not possible, maintainers may call a vote.
The voting process is a simple majority in which each maintainer receives one vote.

### Special Tasks

In addition to the outlined abilities and responsibilities outlined above, some maintainer take on additional tasks and responsibilities.

#### Release Tasks

As a maintainer on the release team, you are expected to:

* Cut releases, and update the [CHANGELOG](./CHANGELOG.md)
* Pre-verify big releases against example repos
* Publish and update versions in example repos
* Verify the release

### Becoming a maintainer

Anyone can become a Kube-rs maintainer. Maintainers should be highly proficient in Rust; have relevant domain expertise; have the time and ability to meet the maintainer expectations above; and demonstrate the ability to work with the existing maintainers and project processes.

To become a maintainer, start by expressing interest to existing maintainers.
Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing code reviews, and other such tasks under their guidance.
After several months of working together, maintainers will decide whether to grant maintainer status.

[coc]: https://github.com/kube-rs/kube-rs/blob/master/code-of-conduct.md
[contrib]: https://github.com/kube-rs/kube-rs/blob/master/CONTRIBUTING.md
23 changes: 23 additions & 0 deletions maintainers.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Maintainers

The Kube-rs maintainers are:

* Eirik Albrigtsen <[email protected]> @clux
* Teo Klestrup Röijezon <[email protected]> @teozkr
* Kaz Yoshihara <[email protected]> @kazk

## Emeriti

Former maintainers include:

* Ryan Levick <[email protected]> @rylev

<!--
# Adding a new maintainer

* Submit a PR modifying this file
* Obtain approvals per governance.md
* Invite maintainer to
https://github.com/orgs/kube-rs/teams/maintainers/members
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this team should be added to cargo owners, so the members can publish/yank versions if necessary (bus factor), but with a restricted right to the crate. https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner

We can also have a separate team (owners/core) dedicated to this purpose. Might be more future-proof if we want to increase the number of maintainers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think there's a bit higher threshold for cargo ownership, it's makes sense for the 3 of us to have it (so I can figure that out), but not sure if it makes sense to scope the crate access (at least without rethinking the shared-version policy) as if you publish one crate you kind of need to publish all of them atm.

We could delineate with a parallel core / owners team, but maybe we could avoid the hierarchical sound here and use something like an adminstrators / release team instead, and then define special/additional maintainer tasks for these. Like; "handling publishing and verifying releases". And then maybe down the line; " handling security disclosure" (currently that's written down as: send an email to 2 maintainers). This way it's not an all or nothing setup to teams.

Copy link
Member Author

@clux clux Oct 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a release team for the purpose of being tied to this access and did:

cargo owner --add github:kube-rs:release

on all crates for it:

Owner team github:kube-rs:release has been added as an owner of crate kube-core
Owner team github:kube-rs:release has been added as an owner of crate kube-derive
Owner team github:kube-rs:release has been added as an owner of crate kube-client
Owner team github:kube-rs:release has been added as an owner of crate kube-runtime
Owner team github:kube-rs:release has been added as an owner of crate kube

only added you to it atm, but will obviously add @teozkr as well if he wants to have the access.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, release team is better. https://crates.io/teams/github:kube-rs:release 🎉

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a need for a minor with the native tls bugfix and teo's kube-derive feature if you want to test it out. If not, I'll release it tomorrow EU morning :-)

(if you do want to; I think it should be pretty safe to follow the release.toml process with up to date tooling - worst case that happens is that it stops half-way through without the root crate being published).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@teozkr I was able to add you to the release team if you want to test it out :-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I'll try doing 0.63 after #677 is merged?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, 0.63 should be out now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. Hope the process wasn't too difficult!

* Invite maintainer to https://github.com/orgs/kube-rs/people
-->