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 1 commit
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
Prev Previous commit
Next Next commit
[Tools Projects] Clean-up after discussion at ContainerCon
  • Loading branch information
@RobDolinMS
RobDolinMS authored Aug 24, 2016
commit c1a42654c54946ea1427583c6bfb61ae6b0e1dd6
44 changes: 35 additions & 9 deletions proposals/tools.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,27 +9,47 @@ 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 Wednesday, June 8th, 2016, the OCI developer community discussed potential location(s) for tools associated with specs.

Pro and con arguments were raised for both:
* A. Having test tools in separate repositories for specs (while possibly keeping schemas with the specs)
* B. Keeping test tools in the same repository as a spec (with independent versioning of files)
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.

The below proposal describes option A.
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
Create runtime-tools and image-tools repositories under the http://github.com/OpenContainers organization.
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 shall be:
Initial maintainers of the runtime-tools project:
* Maintainers of the runtime-spec project
* The four most active contributors (by commit count) to the OCITools project
* Three additional most active contributors (by commit count as of Wed, 8/24/2016) to the repo that will become runtime-tools:
- Ma Shimiao (https://github.com/Mashimiao)
- W. Trevor King (https://github.com/wking)
- Liang Chenye (https://github.com/liangchenye)

(Murnal Patel is one of the most active contributors and he will be included with the first bullet point.)

Initial maintainers of the image-tools project shall be:
* Maintainers of the image-spec project
* Three additional most active contributotors (by commit count as of Wed, 8/24/2016) to the files that will become image-tools:
- Sergiusz Urbaniak (https://github.com/s-urbaniak)
- Antonio Murdaca (https://github.com/runcom)
- xiekeyang (https://github.com/xiekeyang)

(Vincent Batts and Jonathan Boulle are two of the most active contributors and they will be included with the first bullet point.)

### Code of Conduct
Both of the proposed projects would incorporate (by reference) the OCI Code of Conduct from the
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:
Expand All @@ -49,3 +69,9 @@ A: This proposal would not impact runc. Runc containers as a reference implemen

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.