distribution spec
v1.1.0
El proyecto de especificación de distribución de OCI define un protocolo API para facilitar y estandarizar la distribución del contenido.
La especificación se puede encontrar aquí.
Este repositorio también proporciona tipos de GO y herramientas de conformidad de registro. Los tipos de GO y la validación deben ser compatibles con la liberación de GO actual; Los lanzamientos de GO anteriores no son compatibles.
Documentación adicional sobre cómo funciona este grupo:
La especificación de distribución de OCI está estrechamente relacionada con el proyecto de especificación de formato de imagen OCI y el proyecto de especificación de tiempo de ejecución de OCI.
La especificación del formato de imagen OCI define estrictamente los requisitos para una imagen OCI (imagen del contenedor), que consiste en un manifiesto, un índice de imagen opcional, un conjunto de capas del sistema de archivos y una configuración. El esquema para los componentes de la imagen OCI está totalmente compatible con las API definidas en la especificación de distribución de OCI.
La especificación de tiempo de ejecución de OCI define cómo ejecutar correctamente un "paquete del sistema de archivos" de contenedor que se adhiere completamente a la especificación de formato de imagen OCI. La especificación de tiempo de ejecución de OCI es relevante para la especificación de distribución de OCI, ya que ambas admiten imágenes de OCI, y que los tiempos de ejecución de contenedores utilizan las API definidas en la especificación de distribución de OCI para obtener imágenes de contenedores preconstruidas y ejecutarlas.
La especificación de distribución de OCI (este proyecto) también está diseñada genéricamente para ser aprovechada como un mecanismo de distribución para cualquier tipo de contenido. El formato de manifiesto cargado, por ejemplo, no necesariamente debe adherirse a la especificación de formato de imagen OCI siempre que haga referencia a los blobs que comprenden un artefacto dado.
Para obtener preguntas sobre la especificación de distribución de OCI, consulte las preguntas frecuentes.
Para preguntas generales sobre OCI, consulte las preguntas frecuentes en el sitio de OCI.
Los hitos de GitHub establecen el camino hacia las mejoras futuras.
El proyecto de especificación de distribución incluye un proceso y API para prototipos y pruebas de extensiones a la API de distribución.
Invitamos contribuciones, comentarios y revisiones a estas extensiones. Estas extensiones solo avanzarán con un soporte significativo de registros, clientes de registro y usuarios.
Consulte aquí para más detalles.
El desarrollo ocurre en GitHub para la especificación. Los problemas se utilizan para errores y elementos procesables y pueden ocurrir discusiones más largas en la lista de correo.
La especificación y el código tienen licencia bajo la licencia Apache 2.0 que se encuentra en el archivo LICENSE de este repositorio.
El proyecto da la bienvenida a las presentaciones, pero por favor les haga saber a todos en qué está trabajando.
Antes de realizar un cambio no trivial a esta especificación, envíe el correo a la lista de correo para discutir lo que planea hacer. Esto les da a todos la oportunidad de validar el diseño, ayuda a prevenir la duplicación de esfuerzo y asegura que la idea se ajuste. También garantiza que el diseño sea sólido antes de que se escriba el código; Una solicitud de extracción de GitHub no es el lugar para las discusiones de alto nivel.
Los errores tipográficos y gramaticales pueden ir directamente a una solicitud de extracción. En caso de duda, comience en la lista de correo.
Consulte el ReadMe de repositorio de OCI Org para obtener la información más actualizada sobre los horarios de las reuniones de contribuyentes y mantenedores de OCI. También puede encontrar enlaces a las agendas y actas de reuniones para todas las reuniones anteriores.
Puede suscribirse y unirse a la lista de correo en los grupos de Google.
La discusión de OCI ocurre en las siguientes salas de chat, que están unidas juntas:
Para mantener la consistencia a lo largo de los archivos de Markdown en la especificación de contenedor abierto, todos los archivos deben formatearse una oración por línea. Esto soluciona dos cosas: hace que la difusión sea más fácil con GIT y resuelve peleas sobre la longitud de envoltura de línea. Por ejemplo, este párrafo abarcará tres líneas en la fuente de Markdown.
La firma es una línea simple al final de la explicación del parche, que certifica que lo escribió o tiene derecho a transmitirlo como un parche de código abierto. Las reglas son bastante simples: si puede certificar lo siguiente (de Developercertificate.org):
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Entonces simplemente agregas una línea a cada mensaje de confirmación de GIT:
Signed-off-by: Jane Smith <[email protected]>
Usando su nombre real (lo siento, sin seudónimos o contribuciones anónimas).
Puede agregar el inicio de sesión al crear el confirmación de git a través de git commit -s .
Mantenimiento de casa simple para el historial de Git Clean. Lea más sobre cómo escribir un mensaje de confirmación Git o la sección de discusión de git-commit(1) .
