summaryrefslogtreecommitdiff
path: root/vendor/github.com/docker/distribution/MAINTAINERS
diff options
context:
space:
mode:
authorValentin Rothberg <rothberg@redhat.com>2019-06-24 21:29:31 +0200
committerValentin Rothberg <rothberg@redhat.com>2019-06-24 21:29:31 +0200
commit2388222e98462fdbbe44f3e091b2b79d80956a9a (patch)
tree17078d861c20a3e48b19c750c6864c5f59248386 /vendor/github.com/docker/distribution/MAINTAINERS
parenta1a4a75abee2c381483a218e1660621ee416ef7c (diff)
downloadpodman-2388222e98462fdbbe44f3e091b2b79d80956a9a.tar.gz
podman-2388222e98462fdbbe44f3e091b2b79d80956a9a.tar.bz2
podman-2388222e98462fdbbe44f3e091b2b79d80956a9a.zip
update dependencies
Ran a `go get -u` and bumped K8s deps to 1.15.0. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Diffstat (limited to 'vendor/github.com/docker/distribution/MAINTAINERS')
-rw-r--r--vendor/github.com/docker/distribution/MAINTAINERS221
1 files changed, 203 insertions, 18 deletions
diff --git a/vendor/github.com/docker/distribution/MAINTAINERS b/vendor/github.com/docker/distribution/MAINTAINERS
index bda400150..3183620c5 100644
--- a/vendor/github.com/docker/distribution/MAINTAINERS
+++ b/vendor/github.com/docker/distribution/MAINTAINERS
@@ -6,18 +6,198 @@
# It is structured to be consumable by both humans and programs.
# To extract its contents programmatically, use any TOML-compliant parser.
#
-# This file is compiled into the MAINTAINERS file in docker/opensource.
-#
+
+[Rules]
+
+ [Rules.maintainers]
+
+ title = "What is a maintainer?"
+
+ text = """
+There are different types of maintainers, with different responsibilities, but
+all maintainers have 3 things in common:
+
+1) They share responsibility in the project's success.
+2) They have made a long-term, recurring time investment to improve the project.
+3) They spend that time doing whatever needs to be done, not necessarily what
+is the most interesting or fun.
+
+Maintainers are often under-appreciated, because their work is harder to appreciate.
+It's easy to appreciate a really cool and technically advanced feature. It's harder
+to appreciate the absence of bugs, the slow but steady improvement in stability,
+or the reliability of a release process. But those things distinguish a good
+project from a great one.
+"""
+
+ [Rules.reviewer]
+
+ title = "What is a reviewer?"
+
+ text = """
+A reviewer is a core role within the project.
+They share in reviewing issues and pull requests and their LGTM count towards the
+required LGTM count to merge a code change into the project.
+
+Reviewers are part of the organization but do not have write access.
+Becoming a reviewer is a core aspect in the journey to becoming a maintainer.
+"""
+
+ [Rules.adding-maintainers]
+
+ title = "How are maintainers added?"
+
+ text = """
+Maintainers are first and foremost contributors that have shown they are
+committed to the long term success of a 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 three months.
+
+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.
+
+Periodically, the existing maintainers curate a list of contributors that have
+shown regular activity on the project over the prior months. From this list,
+maintainer candidates are selected and proposed on the maintainers mailing list.
+
+After a candidate has been announced on the maintainers mailing list, the
+existing maintainers are given five business days to discuss the candidate,
+raise objections and cast their vote. Candidates must be approved by at least 66% of the current maintainers by adding their vote on the mailing
+list. Only maintainers of the repository that the candidate is proposed for are
+allowed to vote.
+
+If a candidate is approved, a maintainer will contact the candidate to invite
+the candidate to open a pull request that adds the contributor to the
+MAINTAINERS file. The candidate becomes a maintainer once the pull request is
+merged.
+"""
+
+ [Rules.stepping-down-policy]
+
+ title = "Stepping down policy"
+
+ text = """
+Life priorities, interests, and passions can change. If you're a maintainer but
+feel you must remove yourself from the list, inform other maintainers that you
+intend to step down, and if possible, help find someone to pick up your work.
+At the very least, ensure your work can be continued where you left off.
+
+After you've informed other maintainers, create a pull request to remove
+yourself from the MAINTAINERS file.
+"""
+
+ [Rules.inactive-maintainers]
+
+ title = "Removal of inactive maintainers"
+
+ text = """
+Similar to the procedure for adding new maintainers, existing maintainers can
+be removed from the list if they do not show significant activity on the
+project. Periodically, the maintainers review the list of maintainers and their
+activity over the last three months.
+
+If a maintainer has shown insufficient activity over this period, a neutral
+person will contact the maintainer to ask if they want to continue being
+a maintainer. If the maintainer decides to step down as a maintainer, they
+open a pull request to be removed from the MAINTAINERS file.
+
+If the maintainer wants to remain a maintainer, but is unable to perform the
+required duties they can be removed with a vote of at least 66% of
+the current maintainers. An e-mail is sent to the
+mailing list, inviting maintainers of the project to vote. The voting period is
+five business days. Issues related to a maintainer's performance should be
+discussed with them among the other maintainers so that they are not surprised
+by a pull request removing them.
+"""
+
+ [Rules.decisions]
+
+ title = "How are decisions made?"
+
+ text = """
+Short answer: EVERYTHING IS A PULL REQUEST.
+
+distribution is an open-source project with an open design philosophy. This means
+that the repository is the source of truth for EVERY aspect of the project,
+including its philosophy, design, road map, and APIs. *If it's part of the
+project, it's in the repo. If it's in the repo, it's part of the project.*
+
+As a result, all decisions can be expressed as changes to the repository. An
+implementation change is a change to the source code. An API change is a change
+to the API specification. A philosophy change is a change to the philosophy
+manifesto, and so on.
+
+All decisions affecting distribution, big and small, follow the same 3 steps:
+
+* Step 1: Open a pull request. Anyone can do this.
+
+* Step 2: Discuss the pull request. Anyone can do this.
+
+* Step 3: Merge or refuse the pull request. Who does this depends on the nature
+of the pull request and which areas of the project it affects.
+"""
+
+ [Rules.DCO]
+
+ title = "Helping contributors with the DCO"
+
+ text = """
+The [DCO or `Sign your work`](
+https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work)
+requirement is not intended as a roadblock or speed bump.
+
+Some distribution contributors are not as familiar with `git`, or have used a web
+based editor, and thus asking them to `git commit --amend -s` is not the best
+way forward.
+
+In this case, maintainers can update the commits based on clause (c) of the DCO.
+The most trivial way for a contributor to allow the maintainer to do this, is to
+add a DCO signature in a pull requests's comment, or a maintainer can simply
+note that the change is sufficiently trivial that it does not substantially
+change the existing contribution - i.e., a spelling change.
+
+When you add someone's DCO, please also add your own to keep a log.
+"""
+
+ [Rules."no direct push"]
+
+ title = "I'm a maintainer. Should I make pull requests too?"
+
+ text = """
+Yes. Nobody should ever push to master directly. All changes should be
+made through a pull request.
+"""
+
+ [Rules.tsc]
+
+ title = "Conflict Resolution and technical disputes"
+
+ text = """
+distribution defers to the [Technical Steering Committee](https://github.com/moby/tsc) for escalations and resolution on disputes for technical matters."
+ """
+
+ [Rules.meta]
+
+ title = "How is this process changed?"
+
+ text = "Just like everything else: by making a pull request :)"
+
+# Current project organization
[Org]
- [Org."Core maintainers"]
+
+ [Org.Maintainers]
people = [
- "aaronlehmann",
"dmcgowan",
"dmp42",
- "richardscothern",
- "shykes",
"stevvooe",
]
+ [Org.Reviewers]
+ people = [
+ "manishtomar",
+ "caervs",
+ "davidswu",
+ "RobbKistler"
+ ]
[people]
@@ -27,10 +207,15 @@
# ADD YOURSELF HERE IN ALPHABETICAL ORDER
- [people.aaronlehmann]
- Name = "Aaron Lehmann"
- Email = "aaron.lehmann@docker.com"
- GitHub = "aaronlehmann"
+ [people.caervs]
+ Name = "Ryan Abrams"
+ Email = "rdabrams@gmail.com"
+ GitHub = "caervs"
+
+ [people.davidswu]
+ Name = "David Wu"
+ Email = "dwu7401@gmail.com"
+ GitHub = "davidswu"
[people.dmcgowan]
Name = "Derek McGowan"
@@ -42,15 +227,15 @@
Email = "olivier@docker.com"
GitHub = "dmp42"
- [people.richardscothern]
- Name = "Richard Scothern"
- Email = "richard.scothern@gmail.com"
- GitHub = "richardscothern"
+ [people.manishtomar]
+ Name = "Manish Tomar"
+ Email = "manish.tomar@docker.com"
+ GitHub = "manishtomar"
- [people.shykes]
- Name = "Solomon Hykes"
- Email = "solomon@docker.com"
- GitHub = "shykes"
+ [people.RobbKistler]
+ Name = "Robb Kistler"
+ Email = "robb.kistler@docker.com"
+ GitHub = "RobbKistler"
[people.stevvooe]
Name = "Stephen Day"