diff --git a/MAINTAINERS_GUIDE.md b/MAINTAINERS_GUIDE.md index caf27b54dc1..1b05dbed051 100644 --- a/MAINTAINERS_GUIDE.md +++ b/MAINTAINERS_GUIDE.md @@ -7,7 +7,7 @@ features to the project. But most of your time will be spent reviewing, cleaning up, documenting, answering questions, justifying design decisions - while everyone has all the fun! But remember - the quality of the maintainers work is what distinguishes the good projects from the -great. So please be proud of your work, even the unglamourous parts, +great. So please be proud of your work, even the unglamorous parts, and encourage a culture of appreciation and respect for *every* aspect of improving the project - not just the hot new features. @@ -18,7 +18,7 @@ available to them. This is a living document - if you see something out of date or missing, speak up! -## What are a maintainer's responsibility? +## Maintainer's responsibility It is every maintainer's responsibility to: @@ -29,7 +29,7 @@ It is every maintainer's responsibility to: * 4) Make sure their component respects the philosophy, design and roadmap of the project. -## How are decisions made? +## The method of making decisions Short answer: with pull requests to the runc repository. @@ -51,58 +51,58 @@ All decisions affecting runc, big and small, follow the same 3 steps: * Step 2: Discuss the pull request. Anyone can do this. * Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do -this (see below "Who decides what?") +this (see below "Someone who makes decisions") -### I'm a maintainer, should I make pull requests too? +*I'm a maintainer, should I make pull requests too?* Yes. Nobody should ever push to master directly. All changes should be made through a pull request. -## Who decides what? +## Someone who makes decisions All decisions are pull requests, and the relevant maintainers make decisions by accepting or refusing the pull request. Review and acceptance -by anyone is denoted by adding a comment in the pull request: `LGTM`. +by anyone is denoted by adding a comment in the pull request: `LGTM`. However, only currently listed `MAINTAINERS` are counted towards the required two LGTMs. Overall the maintainer system works because of mutual respect across the maintainers of the project. The maintainers trust one another to make decisions -in the best interests of the project. Sometimes maintainers can disagree and +in the best interests of the project. Sometimes maintainers can disagree and this is part of a healthy project to represent the point of views of various people. -In the case where maintainers cannot find agreement on a specific change the -role of a Chief Maintainer comes into play. +In the case where maintainers cannot find agreement on a specific change the +role of a Chief Maintainer comes into play. -The Chief Maintainer for the project is responsible for overall architecture -of the project to maintain conceptual integrity. Large decisions and -architecture changes should be reviewed by the chief maintainer. -The current chief maintainer for the project is Michael Crosby (@crosbymichael). +The Chief Maintainer for the project is responsible for overall architecture +of the project to maintain conceptual integrity. Large decisions and +architecture changes should be reviewed by the chief maintainer. +The current chief maintainer for the project is Michael Crosby (@crosbymichael). Even though the maintainer system is built on trust, if there is a conflict -with the chief maintainer on a decision, their decision can be challenged -and brought to the technical oversight board if two-thirds of the -maintainers vote for an appeal. It is expected that this would be a +with the chief maintainer on a decision, their decision can be challenged +and brought to the technical oversight board if two-thirds of the +maintainers vote for an appeal. It is expected that this would be a very exceptional event. -### How are maintainers added? +### The method of adding maintainers The best maintainers have a vested interest in the project. Maintainers are first and foremost contributors that have shown they are committed to -the long term success of the project. Contributors wanting to become -maintainers are expected to be deeply involved in contributing code, +the long term success of the project. Contributors wanting to become +maintainers are expected to be deeply involved in contributing code, pull request review, and triage of issues in the project for more than two months. -Just contributing does not make you a maintainer, it is about building trust +Just contributing does not make you a maintainer, it is about building trust with the current maintainers of the project and being a person that they can depend on and trust to make decisions in the best interest of the project. The final vote to add a new maintainer should be approved by over 66% of the current -maintainers with the chief maintainer having veto power. In case of a veto, +maintainers with the chief maintainer having veto power. In case of a veto, conflict resolution rules expressed above apply. The voting period is five business days on the Pull Request to add the new maintainer. -### What is expected of maintainers? +### The expectations for maintainers Part of a healthy project is to have active maintainers to support the community in contributions and perform tasks to keep the project running. Maintainers are diff --git a/libcontainer/SPEC.md b/libcontainer/SPEC.md index e5894c6429d..8afd6b45ecf 100644 --- a/libcontainer/SPEC.md +++ b/libcontainer/SPEC.md @@ -306,7 +306,7 @@ a container. | Exec | Execute a new process inside of the container ( requires setns ) | | Set | Setup configs of the container after it's created | -### Execute a new process inside of a running container. +### Execute a new process inside of a running container User can execute a new process inside of a running container. Any binaries to be executed must be accessible within the container's rootfs.