• the new dep has more check
  fix the warnings
• the new dep will do prune if prune is configured
  reduce vendor the code

Doc reviews require a lot of effort and can consume a lot of time for both the review team and the PR creator.

As such, we need to find ways to make the current process a little more streamlined for certain scenarios.

In our current governance policies, we are due to vote on three Architecture Committee seats (@jessfraz @tallclair and @WeiZhang555) in June. However this was written when we were anticipating a Q1 launch. I'd like to propose we push the vote to early September, and consequently push the vote for @sameo and @gnawux's seats to February. We would then stay on the Sept/Feb voting cycle.

Looking to the Architecture Committee to vote on this issue, but open to suggestions and discussion from all.

We need a VENDORING.md file in order to detail how to use dep in different use cases.

The contributor guide needs to state that a git add vendor/ is required after a dep ensure.

See: kata-containers/runtime#1152 (comment).

We need to create a CONTRIBUTING.md document in this repository whose content can be applied to all the other Kata (code) repositories.

Once done, we can create a minimal CONTRIBUTING.md in each other repo that says something like:

For details on how to contribute to the Kata Containers project, please see the main contributing document.

References:

• kata-containers/proxy#14
• kata-containers/proxy#15

Now the March 2019 elections have completed, add a results file to the relevant folder for posterity.

Let's work hard for a better year.

I'd like to see if we can have a mailing list for the VMT members.
The list should be 'closed' (that is, not public), and would be used for:

• an endpoint for reports to the VMT to come in
• a place to subscribe, for instance to the open containers security announcement list

@fungi - is this something we can set up. If so, then I'll update the docs and subscribe the list to the above.

/cc @ttx @vbatts

The contributing guide contains an extraneous bracket that makes the command invalid.

On the homepage (https://katacontainers.io/), the "How to get started" link goes to this GitHub repo, rather than a page that says how to use Kata Containers.

In both #kata-dev and #kata-general channels on IRC, when a user types "kata", Slack generates "@/jessfraz". When jessfraz sends a message in Slack, the IRC user shows up as "kata".

Two weeks ago I made the user "@/kat" on Slack to see if it would jump to pinging that instead, but no dice--stills pings jessfraz.

cc @jbryce

Rework #23 using the assisted PR workflow to get these changes landed.

For clarity, list all members of the Architecture Committee and the Working Committee as a list, with appropriate links.

We are moving off pullapprove.
kata-containers/ci#98

Thus, remove the .pullapprove.yaml in this repo.

Add a guide giving tips on how to review a PR.

When backport/cherry picking commits or PRs to stable branches, should we require that the commits and/or PR message are updated to include a reference back to the original commits (SHAs), and PR (github #nnn's).

This will:

• make it easier and clearer for reviewers the provenance of the backport
• make the providence trail clearer in the git logs
• but shift the onus onto the submitters to do the work of adding these in (ammending the commit messages for instance)

Yes, you can get the info at present by following the Fixes: #nnn link in the PR that is being posted, but it is more work for the reviewers and requires you to hop through github.

Fundamentally this is about providence/crumb-trail and shifting some of the work from the reviewers over to the submitters.

I've added this as an architecture committee topic for 2018-09-17

For Kata Containers we have dispensed with the OWNERS files we used to use in Clear Containers. The reason being it is pointless having to maintain these files along with the .pullapprove.yml files which encode the same information (and more).

Remove mention of the OWNERS files which was an oversight when migrating the doc.

We should require an "ack" from the documentation team before merging any doc changes on PRs.

See kata-containers/documentation#450.

We should probably discuss and define a policy for how we let community members (who are not, at least at present, members of the github kata-containers org access the project. Currently they are limited I believe to some moderately restrictive read-only mode, which carries a couple of potential downsides:

• they cannot assign themselves issues
• they cannot see who the kata members are, or what teams they are in

Now, that may or may not be an issue - we should discuss.

Also, maybe we'd like to discuss and define how somebody can or does become or request to become a member of the kata-containers org. afaik, the members were fixed when the org was formed, and I don't believe we have a method to request, review or add new members.

I do wonder if the github outside collaborators feature could be useful in some form?

/me notes that @annabellebertooch is not a member of the kata org afaict btw ;-)

Our CIs will fail a PR if it does not match our static check requirements. We should document that devs are strongly encouraged to run the static checks locally before PR submission. We also need to document how they do that, and any caveats.

Inspired by: kata-containers/runtime#261

Add a .pullapprove.yml for parity with the other repos and to require 2 acks to sign-off all PRs.

It does not affect kata but we'd like to publish a KCSA for it.

2 seats are up for election, and the election process must start soon.

Related to #59

We need a process on how to become a pull approve approver for each of the repos individually.

@kata-containers/architecture-committee @annabellebertooch @WeiZhang555 @jodh-intel @egernst @grahamwhaley

Hi,
Is it possible to execute .NET on Kata container ?

Do you have a .NET core base image with Kata container ?

With the move from pullapprove to a mixture of github and zuul CI checks, our CONTRIBUTING and review docs need some rework, for example:

• noting that you need to use the github review dialog to register an ack (rather than just lgtm comments)
• better documentaiton around the whole WIP/DNM label/keyword usage

CVE databases etc. use 'Common Platform Enumeration' to detail which products and versions are susceptible to which vulnerabilities.

Now we are starting to process KCSA and KCSN's in the VMT, Should Kata apply for a CPE identifier?
I don't know if the OSF have any precedence or background in this, and maybe already have some appropriate designations? I'd go grab some refs, but the nist website seems to be down!

I was thinking we'd maybe have a CPE of 'osf:kata' or 'kata:kata' for instance.

/cc @ttx @ClaireMassey @fungi @kata-containers/architecture-committee

The contributing guide explains at a high level how to create a PR. Let's be a little more friendly and helpful and include a complete example.

CONTRIBUTING.md currently states that all commits need to have a Fixes #XXX comment, but this is not true. In fact the (critical) patch format section needs a rework.

update the current position

Kata should have a formal method, and team to back that method, for reporting vulnerabilities via a responsible disclosure process.
Document in this repository:

• how to submit a report
• the privacy of such reports
• who receives and handles the reports
• how are the reports handled
• what are the expected timelines
• how are vulnerabilities fixed
  • along with any mitigation details or backports
• how are vulnerabilities disclosed and published
  • to downstream stakeholders
  • publicly

Where possible, diagram the flows and timelines and provide example templates for reporting and disclosing.

All repos need a license file.

We need to create an ARCHITECTURE.md that covers the overall system.

This document could, if necessary, reference architecture documents found in each components repository. These would essentially document just themselves. The intent is to define once and reference as many times as needed.

For example, the ARCHITECTURE.md created in this repository may say something like:

For further details on the Kata shim implementation, refer to the shim architecture document

Component repositories

The individual README.md files in each code repository must contain a reference to this central architecture document.

If a component repository has a separate ARCHITECTURE.md this:

• Must be referenced in the components README.md.
• Must itself reference the central ARCHITECTURE.md document.

For an example of what we should be aiming for, see the Clear Containers architecture document:

• https://github.com/clearcontainers/runtime/blob/master/docs/architecture/architecture.md

Diagrams

All diagrams must:

• Be stored along with their corresponding "source" files (for example, if a .png file is referenced, the .svg file that was used to generate the .png must also be stored to allow the diagrams to be updated by all.
• Use freely available open formats for their sources.

We need to add the code of conduct doc to this repo.

Minutes ago, @lifupan pushed some of his local testing commits to the master branch of kata-containers/runtime repo with vs.code accidentally when he was configuring his new developing laptop. @bergwolf found this and had to reset the commits by turning off the branch protecting temporarily.

@lifupan has disabled the git plugin of his vs.code and reconfigured his git remote config locally.

I did some research but didn't find a way to disable push without pull request in github. Is this possible to protect master from accidentally pushing? Or does 2FA help?

@grahamwhaley @jodh-intel @sboeuf do you have any ideas?

It's a good time for us to create a mission statement for the Kata Containers project! This statement should be fairly brief and tell people what this project aims to do and how we do it.

This issue is for open discussion of what should be included in the mission statement and if anyone wants to suggest drafts.

Examples can be found from OpenStack and Zuul

(this is WIP - I'll start adding details - but if you know of anything missing or have details to add either (if you can) add them yourselves, or leave a comment and I will fold them in. If you are mentioned below, please check you are in the right slot etc. :-)
Eventually this will become a markdown doc or wiki page - probably the former)

Kata uses a number of resources, particularly to drive its CI system for instance. Most of those resources require some sort of access control (keys, logins, rights etc.) to configure, deploy or manage. We don't have a definitive list of what those resources are, or who can access them to maintain them. This can be a fairly critical component to the project, given many of those resource are key blocking parts of the CI system.

Let's collect up a list of all the resources we know of and who currently has the ability to manage them - then we can decide if we need to have a central place to lodge 'credentials', and also if we need to diversify access to avoid any bus factor effects.

We should link the new review rota page (https://github.com/kata-containers/community/wiki/Review-Team-Rota) to both the community md docs in the repo and to the top level wiki page to make it more visible and find-able.

More doc improvements.

I saw a comment somewhere (slack?) where someone was asking whether they could use the kata logo.

We need to document acceptable usage of it and provide an official set of versions of the logo (different background colours, svg + different png-formatted versions, etc).

/cc @annabellebertooch, @gnawux, @egernst, @grahamwhaley.`

We are gaining contributors (yay!). Sometimes they are handling Issues and PRs, or reviewing - and to do that effectively they really need to be part of the kata github organisation so they can action Issues and PRs etc.
I don't believe we have any process, rulings or guidelines on what or how somebody 'qualifies' to become a member of the kata github organisation. We should discuss, and probably define.

@kata-containers/architecture-committee @annabellebertooch @WeiZhang555 @jodh-intel @egernst

N.B. Nominally we could use the github 'collaborators' to give others rights without having to join them to the whole org, but that seems to work on a per-repo basis not a whole org. Maybe that will work for us - I'll leave it here as an option.

Some of the docs in this repo are not referenced by any others, so link them for visibility.

Since Kata Containers does not yet provide an installation option, the current advice for users is to install either Clear Containers or runV since both projects will provide a migration path to Kata Containers at a later date.

If you do not already have an installation of either project, Clear Containers may be the simplest option as packages for common Linux* distributions are provided. However, your choice may depend on the particular project features that interest you.
Installing Clear Containers

See https://github.com/clearcontainers/runtime/wiki/Installation.
Installing runV

See https://github.com/hyperhq/runv.

This section needs to be updated with the latest development.

Fix various issues with the markdown files in this repo.

We need to document what happens if we get a drive-by submission which requires lots of changes to reach our quality standards.

The README.md needs to reference CONTRIBUTING.md.