Maintainers + Governance + Security docs #671
Conversation
Signed-off-by: clux <[email protected]>
we don't do regular meetings - everything is ad-hoc async. Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
| * Submit a PR modifying this file | ||
| * Obtain approvals per governance.md | ||
| * Invite maintainer to | ||
| https://github.com/orgs/kube-rs/teams/maintainers/members |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yeah, release team is better. https://crates.io/teams/github:kube-rs:release 🎉
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
@teozkr I was able to add you to the release team if you want to test it out :-)
There was a problem hiding this comment.
Sure, I'll try doing 0.63 after #677 is merged?
There was a problem hiding this comment.
Looks great. Hope the process wasn't too difficult!
Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
Co-authored-by: kazk <[email protected]>
| 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. |
There was a problem hiding this comment.
Makes sense for now. We'll probably want to revisit this around the 1.0 release.
Co-authored-by: Teo Klestrup Röijezon <[email protected]>
For some CNCF template dd in #670 - but also good things to have for a project.
These are simplified variants of linkerd's process docs in the root of https://github.com/linkerd/linkerd2 (hopefully they'll excuse us mostly using their docs almost verbatim as a starter).
Maintainer Expectations + Becoming a maintainer
For clarity here, I am not trying to force a bunch more work onto any maintainers. I'm just trying to codify how we work based on what we all kind of do, and this is a first sketch which has not been modified a lot.
I don't want this to force anyone out (in fact that's the opposite of what i want), I want this to be relaxed enough to allow for us to just do some of this stuff on the side, while taking into account the natural fluctuations of available time we have - we are all employed after all.
These sections do feel like a nice places for potential new maintainers to learn some of the extra-curricular things we do to set some reasonable expectations.
So if there are any points here you don't like, or are worded too strongly, let's discuss.
The linkerd governance + maintainers setup i started out with is pretty much the same, only changed the following:
Security Policy
Basically taken verbatim from linkerd's policy but we don't have channels, and only release on crates.io, so replaced it with the two last minors released there. Plus this allows us to piggy back RustSec Advisory DB as a communication channel.
Is this a sensible policy? It's not a complete "we don't care about backports at all", but it's also reasonable fast by only doing one extra version back. I don't think these issues should occur that often.
There are still some things we could additionally do here:
Misc
There are more specific aspects of governance that I am still uncertain of (w.r.t. donating the project, project donations - which is becoming a thing - and whether to codify a core governance structure beyond just maintainers/contributors). Also how to do a reasonable roadmap (nice to at least have a place for general future-plans).
But this PR is more of the basic stuff that feels sensible regardless of these unknowns. It would give some clarity to people wanting to use us regardless of how the end result with CNCF/kubernetes ends up.