Skip to content

Commit e734841

Browse files
authored
Merge pull request #233 from bloodorangeio/readme-updates
Rewrite README based on image spec
2 parents d8b559c + e630d5b commit e734841

File tree

2 files changed

+147
-24
lines changed

2 files changed

+147
-24
lines changed

faq.md renamed to FAQ.md

File renamed without changes.

README.md

Lines changed: 147 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -1,41 +1,164 @@
1-
## Open Container Initiative Distribution Specification
1+
# OCI Distribution Specification
22

3-
The [Open Container Initiative](https://www.opencontainers.org/) develops specifications for standards on Operating System process and application containers.
3+
The OCI Distribution Spec project defines an API protocol to facilitate and standardize the distribution of content.
44

5-
The specification can be found [here](https://github.com/opencontainers/distribution-spec/blob/master/spec.md).
5+
**[The specification can be found here](spec.md).**
66

7-
### Table of Contents
7+
This repository also provides [Go types](specs-go), and [registry conformance tooling](conformance).
8+
The Go types and validation should be compatible with the current Go release; earlier Go releases are not supported.
89

9-
- [Code of Conduct][code-of-conduct]
10+
Additional documentation about how this group operates:
11+
12+
- [Contributing](CONTRIBUTING.md)
13+
- [Governance](GOVERNANCE.md)
14+
- [Maintainers' Guide](MAINTAINERS_GUIDE.md)
1015
- [Releases](RELEASES.md)
11-
- [Charter][charter]
12-
- [Frequently Asked Questions](faq.md)
1316

14-
### Use Cases
17+
The _optional_ and _base_ layers of all OCI projects are tracked in the [OCI Scope Table](https://www.opencontainers.org/about/oci-scope-table).
18+
19+
## Distributing OCI Images and other content
20+
21+
The OCI Distribution Spec is closely related to the [OCI Image Format Specification] project,
22+
the [OCI Runtime Specification] project,
23+
and the [OCI Artifacts] project.
24+
25+
The [OCI Image Format Specification] strictly defines the requirements for an OCI Image (container image), which consists of
26+
a manifest, an optional image index, a set of filesystem layers, and a configuration.
27+
The schema for OCI Image components is fully supported by the APIs defined in the OCI Distribution Specification.
28+
29+
The [OCI Runtime Specification] defines how to properly run a container "[filesystem bundle](https://github.com/opencontainers/runtime-spec/blob/master/bundle.md)"
30+
which fully adheres to the OCI Image Format Specification. The OCI Runtime Specification is relevant to the OCI Distribution Specification in that they both support OCI Images,
31+
and that container runtimes use the APIs defined in the OCI Distribution Specification to fetch pre-built container images and run them.
32+
33+
The [OCI Distribution Specification] (this project) is also designed generically enough to be leveraged as a distribution mechanism for
34+
any type of content. The format of uploaded manifests, for example, need not necessarily adhere to the OCI Image Format Specification
35+
so long as it references the blobs which comprise a given artifact.
36+
37+
The [OCI Artifacts] project is an effort to provide guidance on how to
38+
properly define and distribute content using the OCI Distribution Specification for artifacts which are not container filesystem bundles,
39+
in a way that is mostly compatible with the existing schemas defined in the OCI Image Format Specification.
40+
41+
[OCI Image Format Specification]: https://github.com/opencontainers/image-spec
42+
[OCI Runtime Specification]: https://github.com/opencontainers/runtime-spec
43+
[OCI Distribution Specification]: https://github.com/opencontainers/distribution-spec
44+
[OCI Artifacts]: https://github.com/opencontainers/artifacts
45+
46+
## FAQ
47+
48+
For questions about the OCI Distribution Specification, please see the [FAQ](FAQ.md).
49+
50+
For general questions about OCI, please see the [FAQ on the OCI site](https://www.opencontainers.org/faq).
51+
52+
## Roadmap
53+
54+
The [GitHub milestones](https://github.com/opencontainers/distribution-spec/milestones) lay out the path to the future improvements.
55+
56+
# Contributing
57+
58+
Development happens on GitHub for the spec.
59+
Issues are used for bugs and actionable items and longer discussions can happen on the [mailing list](#mailing-list).
60+
61+
The specification and code is licensed under the Apache 2.0 license found in the `LICENSE` file of this repository.
62+
63+
## Discuss your design
64+
65+
The project welcomes submissions, but please let everyone know what you are working on.
66+
67+
Before undertaking a nontrivial change to this specification, send mail to the [mailing list](#mailing-list) to discuss what you plan to do.
68+
This gives everyone a chance to validate the design, helps prevent duplication of effort, and ensures that the idea fits.
69+
It also guarantees that the design is sound before code is written; a GitHub pull-request is not the place for high-level discussions.
70+
71+
Typos and grammatical errors can go straight to a pull-request.
72+
When in doubt, start on the [mailing-list](#mailing-list).
73+
74+
## Meetings
75+
76+
Please see the [OCI org repository README](https://github.com/opencontainers/org#meetings) for the most up-to-date information on OCI contributor and maintainer meeting schedules.
77+
You can also find links to meeting agendas and minutes for all prior meetings.
78+
79+
## Mailing List
80+
81+
You can subscribe and join the mailing list on [Google Groups](https://groups.google.com/a/opencontainers.org/forum/#!forum/dev).
82+
83+
## Chat
84+
85+
OCI discussion happens in the following chat rooms, which are all bridged together:
86+
87+
- #general channel on [OCI Slack](https://chat.opencontainers.org/)
88+
- #opencontainers:matrix.org
89+
- #opencontainers on freenode.net
90+
91+
## Markdown style
92+
93+
To keep consistency throughout the Markdown files in the Open Container spec all files should be formatted one sentence per line.
94+
This fixes two things: it makes diffing easier with git and it resolves fights about line wrapping length.
95+
For example, this paragraph will span three lines in the Markdown source.
96+
97+
## Git commit
98+
99+
### Sign your work
100+
101+
The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch.
102+
The rules are pretty simple: if you can certify the below (from [developercertificate.org](http://developercertificate.org/)):
103+
104+
```
105+
Developer Certificate of Origin
106+
Version 1.1
107+
108+
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
109+
660 York Street, Suite 102,
110+
San Francisco, CA 94110 USA
111+
112+
Everyone is permitted to copy and distribute verbatim copies of this
113+
license document, but changing it is not allowed.
114+
115+
116+
Developer's Certificate of Origin 1.1
117+
118+
By making a contribution to this project, I certify that:
15119
16-
Following sections give context for aspects of this specification:
120+
(a) The contribution was created in whole or in part by me and I
121+
have the right to submit it under the open source license
122+
indicated in the file; or
17123
18-
### Registry Developers
124+
(b) The contribution is based upon previous work that, to the best
125+
of my knowledge, is covered under an appropriate open source
126+
license and I have the right under that license to submit that
127+
work with modifications, whether created in whole or in part
128+
by me, under the same open source license (unless I am
129+
permitted to submit under a different license), as indicated
130+
in the file; or
19131
20-
### Registry Administrators
132+
(c) The contribution was provided directly to me by some other
133+
person who certified (a), (b) or (c) and I have not modified
134+
it.
21135
22-
### Client Side Image Tools
136+
(d) I understand and agree that this project and the contribution
137+
are public and that a record of the contribution (including all
138+
personal information I submit with it, including my sign-off) is
139+
maintained indefinitely and may be redistributed consistent with
140+
this project or the open source license(s) involved.
141+
```
23142

24-
### Container Image Pipeline
143+
then you just add a line to every git commit message:
25144

26-
## Contributing
145+
Signed-off-by: Jane Smith <[email protected]>
27146

28-
See [our contribution documentation](CONTRIBUTING.md).
147+
using your real name (sorry, no pseudonyms or anonymous contributions.)
29148

30-
Development happens on GitHub.
31-
Responsible disclosure for security issues is discussed [here](CONTRIBUTING.md#security-issues).
32-
[Issues][issues] are used for non-security bugs and actionable items; longer discussions can happen on the [mailing list](#mailing-list).
149+
You can add the sign off when creating the git commit via `git commit -s`.
33150

34-
### Mailing list
151+
### Commit Style
35152

36-
You can subscribe and browse the mailing list on [Google Groups][mailing-list].
153+
Simple house-keeping for clean git history.
154+
Read more on [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/) or the Discussion section of [`git-commit(1)`](http://git-scm.com/docs/git-commit).
37155

38-
[charter]: https://www.opencontainers.org/about/governance
39-
[code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md
40-
[issues]: https://github.com/opencontainers/distribution-spec/issues
41-
[mailing-list]: https://groups.google.com/a/opencontainers.org/forum/#!forum/dev
156+
1. Separate the subject from body with a blank line
157+
2. Limit the subject line to 50 characters
158+
3. Capitalize the subject line
159+
4. Do not end the subject line with a period
160+
5. Use the imperative mood in the subject line
161+
6. Wrap the body at 72 characters
162+
7. Use the body to explain what and why vs. how
163+
* If there was important/useful/essential conversation or information, copy or include a reference
164+
8. When possible, one keyword to scope the change in the subject (i.e. "README: ...", "runtime: ...")

0 commit comments

Comments
 (0)