-
Notifications
You must be signed in to change notification settings - Fork 554
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
Cleanup the spec a bit to remove WG/git text that's not really part of the spec #626
Conversation
@@ -7,6 +7,14 @@ Releases are proposed and adopted or rejected using the usual [project governanc | |||
An anti-pattern that we want to avoid is heavy development or discussions "late cycle" around major releases. | |||
We want to build a community that is involved and communicates consistently through all releases instead of relying on "silent periods" as a judge of stability. | |||
|
|||
## Release Process |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old project.md
was runtime-spec-specific notes. This RELEASES.md
is generic OCI policy. I'd rather keep those in separate files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From an end-user perspective just trying to understand things I don't see much of a diff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-maintainers have to understand neither, all maintainers have to understand the current RELEASES.md
, and only @vbatts (or whoever is cutting the release) needs to understand the notes you're moving here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i also think runtime-spec specific process doesnt need to be in the same file as the generic oci release.md. Maybe these can just be in README ? Separating makes it easier to apply upstream Release.md changes too if necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok - re-reading the RELEASES.md file.... I have no idea why that file is even here :-)
If its not runtime-spec specific then it shouldn't be in this repo at all. I'm inclined to say we remove it entirely and put it at a higher level in the OCI git repo structure, but let's do that in a separate PR. For now, there should just be one runtime-spec release process/guidance doc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If its not runtime-spec specific then it shouldn't be in this repo at all. I'm inclined to say we remove it entirely and put it at a higher level in the OCI git repo structure, but let's do that in a separate PR.
The release-doc issue seems orthogonal to the README decoupling, so I'd rather not touch them in this PR.
And the local copy is because each project can tweak the generic docs, although they're encouraged not to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
darn - thought I did that - fixed - thanks
@@ -595,7 +595,7 @@ The values MUST be absolute paths in the [container namespace][container-namespa | |||
"mountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c715,c811" | |||
``` | |||
|
|||
[container-namespace]: glossary.md#container_namespace | |||
[container-namespace2]: glossary.md#container_namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pdf generation tool was generating a warning message so this is one way to avoid that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably worth putting the warning message in your commit message so that that's clear in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There's some overlap between this and my work-in-progress AsciiDoc translation (#615), but I'm fine rerolling my AsciiDoc if this lands first. |
Needs rebase. |
rebased - I think I got the changes right. |
## Code of Conduct | ||
|
||
Participation in the OCI community is governed by the [OCI Code of Conduct](https://github.com/opencontainers/tob/blob/d2f9d68c1332870e40693fe077d311e0742bc73d/code-of-conduct.md). | ||
|
||
======= | ||
>>>>>>> 2d08a81... Cleanup the spec a bit to remove WG/git text that's not really part of the spec |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Busted rebase?
@wking fixed rebase issue - thanks |
An implementation is not compliant for a given CPU architecture if it fails to satisfy one or more of the MUST, REQUIRED, or SHALL requirements for the protocols it implements. | ||
An implementation is compliant for a given CPU architecture if it satisfies all the MUST, REQUIRED, and SHALL requirements for the protocols it implements. | ||
|
||
[rfc2119]: http://tools.ietf.org/html/rfc2119 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can drop this from the README now that you've shifted the consumer over here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And you still need to shift over the c99-unspecified
definition.
fixed extra/missing refs and backed-out the 'releases' stuff - will save for another PR. |
* Linux containers: [runtime.md](runtime.md), [config.md](config.md), [config-linux.md](config-linux.md), and [runtime-linux.md](runtime-linux.md). | ||
* Solaris containers: [runtime.md](runtime.md), [config.md](config.md), and [config-solaris.md](config-solaris.md). | ||
* Windows containers: [runtime.md](runtime.md), [config.md](config.md), and [config-windows.md](config-windows.md). | ||
[charter]: https://www.opencontainers.org/about/governance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should move back into RELEASES.md
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
…f the spec renamed an href to "container-namespace2" to avoid a dup-warning msg from the PDF generator Signed-off-by: Doug Davis <dug@us.ibm.com>
1 similar comment
e7be40f looks good to me.
|
Now that d43fc42 (config-linux: Lift no-tweaking namespace restriction, 2017-01-11, opencontainers#649) allows us to get into this sort of situation. This sort of ownership may also apply to other resources (cgroups?), but we can handle them in follow-up commits. Also drop "Configuration" from the root header. Everything in that file is a configuration. container-namespace3 (instead of container-namespace) supports the single-page, Pandoc-generated file (see e7be40f, Cleanup the spec a bit to remove WG/git text that's not really part of the spec, 2016-11-14, opencontainers#626). Signed-off-by: W. Trevor King <wking@tremily.us>
Now that d43fc42 (config-linux: Lift no-tweaking namespace restriction, 2017-01-11, opencontainers#649) allows us to get into this sort of situation. This sort of ownership may also apply to other resources (cgroups?), but we can handle them in follow-up commits. Also drop "Configuration" from the root header. Everything in that file is a configuration. container-namespace3 (instead of container-namespace) supports the single-page, Pandoc-generated file (see e7be40f, Cleanup the spec a bit to remove WG/git text that's not really part of the spec, 2016-11-14, opencontainers#626). Using an informative suggestion was recommended by Dao Quang Minh [1]. I've made the config JSON as small as possible while keeping it valid, but there's still an unfortunate amount of boilerplate there. There is in-flight work to let us at least drop process.args [2]. [1]: opencontainers#651 [2]: opencontainers#620 Signed-off-by: W. Trevor King <wking@tremily.us>
Now that d43fc42 (config-linux: Lift no-tweaking namespace restriction, 2017-01-11, opencontainers#649) allows us to get into this sort of situation. This sort of ownership may also apply to other resources (cgroups?), but we can handle them in follow-up commits. Using an informative suggestion was recommended by Dao Quang Minh [1]. I've made the config JSON as small as possible while keeping it valid, but there's still an unfortunate amount of boilerplate there. There is in-flight work to let us at least drop process.args [2]. The new mount namespace in the UTS example avoids pivoting the host namespace's root. Also drop "Configuration" from the root header. Everything in that file is a configuration. container-namespace3 (instead of container-namespace) supports the single-page, Pandoc-generated file (see e7be40f, Cleanup the spec a bit to remove WG/git text that's not really part of the spec, 2016-11-14, opencontainers#626). [1]: opencontainers#651 [2]: opencontainers#620 Signed-off-by: W. Trevor King <wking@tremily.us>
The capitalization in "Container Configuration file" (which we've used since 70372d3, *.md: update TOC and links, 2015-09-10, opencontainers#176) was halfway between "Title Case" and "Sentence case". The current spec isn't particularly consistent (e.g. we have both "Specification version" and "POSIX process"), but the ToC has used "Configuration" for this file since e7be40f (Cleanup the spec a bit to remove WG/git text that's not really part of the spec, 2016-11-14, opencontainers#626) so dodge the sentence/title issue and use that here too. Signed-off-by: W. Trevor King <wking@tremily.us>
The capitalization in "Container Configuration file" (which we've used since 70372d3, *.md: update TOC and links, 2015-09-10, opencontainers#176) was halfway between "Title Case" and "Sentence case". The current spec isn't particularly consistent (e.g. we have both "Specification version" and "POSIX-platform Mounts"), but the ToC has used "Configuration" for this file since e7be40f (Cleanup the spec a bit to remove WG/git text that's not really part of the spec, 2016-11-14, opencontainers#626) so dodge the sentence/title issue and use that here too. Signed-off-by: W. Trevor King <wking@tremily.us>
First pass - and a little bit of extra clean-up. Per the f2f at kubecon.
Signed-off-by: Doug Davis dug@us.ibm.com