Skip to content
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.

Sign up for GitHub

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

Create runtime-tools and image-tools projects #18

Merged
merged 7 commits into from
Sep 8, 2016
Merged

Create runtime-tools and image-tools projects #18

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
4fa7473
[Tools Projects] Initial Draft
RobDolinMS Jun 15, 2016
9b30645
[Tools Projects] Fix typo
RobDolinMS Jun 15, 2016
bd02c03
[Tools Projects] Add FAQ
RobDolinMS Jun 15, 2016
c1a4265
[Tools Projects] Clean-up after discussion at ContainerCon
RobDolinMS Aug 24, 2016
59d6f09
[Tools Projects] Fix typos, add FAQ
RobDolinMS Aug 29, 2016
e9b6d54
[Tools Projects] Add links to charter and scope table
RobDolinMS Aug 31, 2016
0219367
Initial tools maintainers == spec maintainers
RobDolinMS Sep 7, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 78 additions & 0 deletions proposals/tools.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
# OCI Runtime-Tools and Image-Tools Project Proposals

## Abstract
The below proposal contemplates creation of two tools projects (runtime-tools and image-tools.)
These would be associated with the OCI specification projects (runtime-spec and image-spec) and serve as repositories for testing tools.

## Background
Testing tools have been organically developed by the OCI developer community.
These include:
* Runtime-spec test code in a OCITools repository
* Image-spec test code in the image-spec repository

On Monday, August 22nd, 2016, the OCI Certification Program WG designated Chris Aniszczyk and Rob Dolin to draft a proposal for formalizing approval of tools.

On Wednesday, August 24th, 2016, the OCI Developer Community (TDC) met and recommended establishing a tools repository corresponding to each of the spec repositories.

## Proposal
With repositories under the http://github.com/OpenContainers organization:
* Rename the OCITools repository as runtime-tools
* Create a new repository named image-tools and populate this with the files from: https://github.com/opencontainers/image-spec/tree/master/cmd/oci-image-tool
Copy link
Contributor

@wking wking Aug 30, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In off-list discussion starting here, I think (and understand @RobDolinMS to agree) that we want to say that the repo names should end with {component}-tools (e.g. runtime-tools). That way the tool maintainers can choose oci-runtime-tools (e.g. to match an installed command) if they like, or choose runtime-tools if there is no installed command to match, or if they (for whatever reason) don't want the repo name to match the installed command.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a bit more research on this and recommend against attempting to align the repo names with CLI commands. Today, the CLI commands are "ocitools" for runtime and "oci-image-tool" for image.

Antonio (@runcom) has also suggested that we use the plural ("tools") instead of singular ("tool") since more tools may be developed in the future.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on calling it image-tools and runtime-tools. Ship it!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@philips LGTM! I think this is ready to do an email vote via the @opencontainers/tob mailing list.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Aug 31, 2016 at 02:45:12PM -0700, Rob Dolin (MSFT) wrote:

+* Create a new repository named image-tools and populate this with the files from: https://github.com/opencontainers/image-spec/tree/master/cmd/oci-image-tool

I did a bit more research on this and recommend against attempting
to align the repo names with CLI commands. Today, the CLI commands
are "ocitools" for runtime and "oci-image-tool" for image.

I was expecting we'd rename the installed commands to oci-*-tools. No
sense in having two names when we can use one ;).


### Project Descriptions
Below are brief draft project descriptions intended to serve as an initial abstract for each project:
* Runtime-Tools: Tools for testing of container runtimes implementing the OCI runtime-spec.
This includes code that tests a runtime's conformance to the OCI Container Runtime spec.
* Image-Tools: Tools for testing of container images implementing the OCI image-spec.
This includes code that validates a file's conformance to the OCI Container Image Format spec.

### Initial Maintainers
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this voting happen separately?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@crosbymichael This is a good question about initial maintainers (and how to add/remove maintainers.) I've seen organizations do things multiple ways with the three most common being:

  • Project proposal (or org charter) lists initial leadership (IIRC, OCI did this with runc maintainers and runtime-spec maintainers)
  • Election for initial leadership (IIRC, OCI did this with TOB membership and the image-spec maintainers)
  • Pay to be in leadership (I've seen orgs with membership pricing tiers do this)

I thought making the specs repo maintainers the initial maintainers of the tools repos and adding the next three active contributors seemed reasonable.

(I also assume that anyone can opt-out of being a maintainer at any time.)

I would like to see OCI clarify how maintainers are added and removed after project creation since the OCI charter is a bit vague on this, but that's probably an issue for another pull request.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Aug 31, 2016 at 03:22:20PM -0700, Rob Dolin (MSFT) wrote:

I would like to see OCI clarify how maintainers are added and
removed after project creation since the OCI charter is a bit vague
on this, but that's probably an issue for another pull request.

§5.b.viii.2 and .3 delegate maintainer addition/removal to the
(per-project?) TDC(s?).

The TDC-maintained (I think ;) project-template has those rules for
maintainer addition 1, although not all OCI Projects have adopted
them yet (by merging them into the per-project repo). Removing
maintainers is not clear, but probably follows the two-thirds vote
dicussed in that doc for other purposes (it would be nice to spell it
out explicitly).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we have pretty clear rules around how maintainers are added. The initial set is usually the existing maintainers since these new projects have the same scope. Additional maintainers should be separate votes based on the individuals

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typically for runc, we have had sponsor maintainers who propose someone and then we follow the 2/3 vote. We can follow the same process here as well. If it isn't clear, then we could clarify it as such.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Aug 31, 2016 at 03:54:52PM -0700, Michael Crosby wrote:

I think we have pretty clear rules around how maintainers are added.
The initial set is usually the existing maintainers since these new
projects have the same scope. Additional maintainers should be
separate votes based on the individuals

This makes sense to me, and saves the TOB some thinking.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Aug 31, 2016 at 03:57:28PM -0700, Mrunal Patel wrote:

Typically for runc, we have had sponsor maintainers who propose
someone and then we follow the 2/3 vote…

Hmm. I don't see anything about sponsors in [1,2]. If that's really
intended to be a requirement for new OCI Projects, someone should PR
project-template and call for a TDC vote.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Aug 31, 2016 at 03:54:52PM -0700, Michael Crosby wrote:

The initial set is usually the existing maintainers since these new
projects have the same scope.

For clarity in the runtime tools case, I think this should be the
union of [1,2].

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per discussion on the OCI Dev / TDC ConCall today, I have updated this PR to just have the initial maintainers of the tools projects be the initial maintainers of the specs projects.
/cc @crosbymichael @wking @mrunalp @philips

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Sep 07, 2016 at 02:43:05PM -0700, Rob Dolin (MSFT) wrote:

+### Initial Maintainers

Per discussion on the OCI Dev / TDC ConCall today, I have updated
this PR to just have the initial maintainers of the tools projects
be the initial maintainers of the specs projects.

0219367 needs a Signed-off-by, but otherwise looks good to me.

Initial maintainers of the runtime-tools project:
* Maintainers of the runtime-spec project

Initial maintainers of the image-tools project shall be:
* Maintainers of the image-spec project

### Code of Conduct
Both of the proposed projects would incorporate (by reference) the OCI Code of Conduct

### Governance and Releases
Both of the proposed projects would incorporate the Governance and Releases processes from the OCI project template: https://github.com/opencontainers/project-template.

### Project Communications
Both of the proposed projects would continue to use existing channels in use by the OCI developer community for communication including:
* GitHub for issues and pull requests
* The dev@opencontainers.org email list
* The weekly OCI developer community conference call
* The #OpenContainers IRC channel

### Versioning / Roadmap
Released version numbers of the runtime-tools and image-tools projects should roughly align with released verions of the associated specs projects.

It is expected that releases of the tools projects will follow releases of the specs projects by anywhere from a few days to a few months.

## Frequenty Asked Questions (FAQ)
Q: What about the runc project?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“runc” → “runC”?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally prefer PascalCase or lowerCamelCase for readability, but the runc project readme uses alllowercase.

A: This proposal would not impact runc.
Runc is a reference implementation of the runtime-spec and it lives in its own repo.

Q: What about schemas?
A: It would be up to the OCI developer community to determine if schemas fit best with the specs or tools projects.

Q: Why are the repo names plural (tools) instead of singular (tool)?
A: There may be multiple tools or a single tool with multiple functionalities.

Q: Why not prefix the repo names with "oci-" aligning to the CLI commands for invoking the tools?
A: The repos will be under the http://www.github.com/OpenContainers/ organization.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the flexible repo-naming proposal goes through, we'd want to drop this FAQ.


Q: Why two tools repos?
A: Having a tools repo for each spec repo allows for releasing a tools repo shortly after a spec stabilizes even if the other tools repo is in a state of flux.

Q: Why is contribution count used to identify potential maintainers?
A: Contribution count is not a great metric for the value of a contributor's contributions, but this seemed like a reasonable, rough way to identify additional potential maintainers beyond the spec maintainers.

Q: Can additional code/tools be added to the proposed tools repos beyond what is listed above?
A: Yes. If there is other code or functionality that a contributor believes would be relevant for runtime-related or image-related tools, it would be great if it is contributed.

Q: Does this change the OCI Charter or Scope Table?
A: No. Nothing in this proposal is intended to amend the OCI Charter (https://www.opencontainers.org/about/governance) or OCI Scope Table (https://www.opencontainers.org/governance/oci-scope-table).