-
Notifications
You must be signed in to change notification settings - Fork 22
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
Add governance and releases docs #15
Add governance and releases docs #15
Conversation
This is a proposed process for approval of new releases of specifications and projects from the OCI. The creation of this process is designed to clarify how a release gets created and who needs to sign off.
I got some feedback from folks that some motivation early in the document might be helpful for why the process encourages regular communication.
Requiring applications wait 1 week to get feedback before making a release, removing "business day" wording @cyphar, @stevvooe, and @wking were in the discussion.[1] [1] opencontainers/tob#15 (comment)
Requiring the _minimum_ process for a major release to be 3 rcs and a final release. This will establish a _minimum_ timeline of 1 month to get to a release assuming zero required changes. @stevvooe, @wking were in this discussion. opencontainers/tob#15 (comment)
Changing the release goal for projects to a "SHOULD monthly release" from the original bi-weekly. @diogomonica, @stevvooe, @mrunalp, @RobDolinMS were in that discussion opencontainers/tob#15 (comment)
Fix up the language around REJECTs so it is easier to understand. The basic premise is that a release may continue with REJECTs if 2/3 of the maintainers vote to make the release. But, the maintainers SHOULD discuss and allow time for any REJECTs to become LGTMs. Spread over two discussions: [1](https://github.com/opencontainers/tob/pull/15/files/bdfa70d70f093146bc730be2576586ec8ed57cca#r66519789) and [2](https://github.com/opencontainers/tob/pull/15/files/bdfa70d70f093146bc730be2576586ec8ed57cca#r66668148)
The intention of the voting members language is to ensure that releases can proceed even if people are unresponsive, on vacation, etc without ambiguity. This is similar to how the TOB operates. Identified by @wking here: opencontainers/tob#15 (comment)
Based on discussion with wking and mrunalp participating and Stephen Day acking in IRC: opencontainers/tob#15 (comment)
This addresses @stevvooe's concern about GitHub issues being the only medium for discussion of a reject. @wking and @philips were involved in this discussion: opencontainers/tob#15 (comment)
Projects have a happy path and a slow path. The happy path is a release with maintainers agreeing and a timeout. The slow path has rejects and quorums. Based on discussion with @wking opencontainers/tob#15 (comment)
Instead of being prescriptive provide suggestions instead for how to provide release REJECTS feedback. Based on feedback from Stephen Day and @wking.
Fixup qourum typos based on feedback from @wking.
Avoid duplication by collecting common ideas (e.g. list-based voting) in their own sections. After this reshuffling, it became apparent that there were no special application restrictions, so I added additional language to motivate the specification-specific additions. Signed-off-by: W. Trevor King <wking@tremily.us>
philips/tob#1 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Reported by Tianon opencontainers/tob#15 (comment)
Expand a bit more information about the security@ alias and who is involved in a security sensitive release.
c9a01f5
to
c0774ac
Compare
This is useful for more than release approval. For example, it's useful for updating the project governance document itself [1]. I've also tried to address Jason's other points, except for defining a "breaking change" (since that is tied up in [2]). New wording about motions and whatnot is pulled from Roberts' [3], see proposing a motion (RRoO I.4, p33) and seconding a motion (RRoO I.5, p36). The subject templates I just made up on my own after thinking over the initial proposal emails (e.g. [4]). I also pulled in the one-sentence pattern [5] since I was touching so much. [1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/ik3MIDWq4Us/Zx1JUStXBAAJ Subject: Re: Vote Required: OCI Image Spec Release Process Date: Fri, 24 Jun 2016 16:58:58 -0700 Message-ID: <CAFi6z1HAkKbnMoAXubyGusQJ_MromgpQ4qHCQ3R9_NwZNYBX5w@mail.gmail.com> [2]: opencontainers/tob#16 [3]: http://archive.org/details/Robertsrulesofor00robe_201303 [4]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/ik3MIDWq4Us Subject: Vote Required: OCI Image Spec Release Process Date: Thu, 23 Jun 2016 15:56:40 +0000 Message-ID: <CAD2oYtNnW+hP7Q3NPBdYHOKfigU0pvbgcphKPhRB=ZfQBwX8VA@mail.gmail.com> [5]: opencontainers/tob#15 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Split files into governance and releases and outline the maintainers of the GOVERNANCE doc itself. Signed-off-by: Brandon Philips <brandon.philips@coreos.com>
c0774ac
to
56abe12
Compare
@philips is this ready for review? |
oh right. I didn't put the two together. |
LGTM @caniszczyk can you LGTM this so we can merge it. The vote passed: https://groups.google.com/a/opencontainers.org/d/msg/dev/x-Oh3PDz1Y8/q7t2IseVAwAJ |
This series is not consistently Signed-off-by. Maybe squash down to a
single commit before merging? I'm fine if I don't get listed as a
co-author, but you can add my Signed-off-by to the squashed commit.
|
@wking I would rather just merge this as-is even though the signed-off-by's are missing. I can certainly squash. @caniszczyk do you mind merging it as-is? |
On Thu, Jul 21, 2016 at 01:10:16PM -0700, Brandon Philips wrote:
Since it's just your commits without the Signed-off-by's, maybe the |
Next step is to copy these over to runc/runtime-spec/image-spec repos |
On Thu, Jul 21, 2016 at 03:29:24PM -0700, Chris Aniszczyk wrote:
Where are we with #4? It would be nice if after an all-maintainer $ git pull git://github.com/opencontainers/project-template.git in runtime-spec and push it to master without bothering with |
I'd garbled the old '#release-approval' target in c732cc2 (project-governance: Make voting more generic, 2016-06-24, opencontainers#15). Signed-off-by: W. Trevor King <wking@tremily.us>
I'd garbled the old '#release-approval' target in c732cc2 (project-governance: Make voting more generic, 2016-06-24, opencontainers#15). Signed-off-by: W. Trevor King <wking@tremily.us>
I'd missed this in c732cc2 (project-governance: Make voting more generic, 2016-06-24, opencontainers#15). Signed-off-by: W. Trevor King <wking@tremily.us>
This is a proposed process for approval of new releases of
specifications and projects from the OCI.
The creation of this process is designed to clarify how a release gets
created and who needs to sign off.
Replaces opencontainers/tob#15