Add maintainers and authors

Signed-off-by: Sebastiaan van Stijn <[email protected]>

.mailmap

@@ -0,0 +1,6 @@
+# This file lists all individuals having contributed content to the repository.
+# For how it is generated, see `hack/generate-authors`.
+
+Tibor Vass <[email protected]>
+Tibor Vass <[email protected]> <[email protected]>
+Tõnis Tiigi <[email protected]>

AUTHORS

@@ -0,0 +1,7 @@
+# This file lists all individuals having contributed content to the repository.
+# For how it is generated, see `scripts/generate-authors.sh`.
+
+Bin Du <[email protected]>
+Brian Goff <[email protected]>
+Tibor Vass <[email protected]>
+Tõnis Tiigi <[email protected]>

MAINTAINERS

@@ -0,0 +1,192 @@
+# Buildx maintainers file
+#
+# This file describes the maintainer groups within the project.
+# More detail on Moby project governance is available in the
+# https://github.com/moby/moby/blob/master/project/GOVERNANCE.md file.
+#
+# It is structured to be consumable by both humans and programs.
+# To extract its contents programmatically, use any TOML-compliant
+# parser.
+#
+
+[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.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.
+
+After a candidate has been announced, 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 slack
+channel. 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.  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.DCO]
+
+		title = "Helping contributors with the DCO"
+
+		text = """
+The [DCO or `Sign your work`](
+https://github.com/moby/buildkit/blob/master/CONTRIBUTING.md#sign-your-work)
+requirement is not intended as a roadblock or speed bump.
+
+Some BuildKit 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.meta]
+
+		title = "How is this process changed?"
+
+		text = "Just like everything else: by making a pull request :)"
+
+
+[Org]
+
+	[Org.Maintainers]
+
+		people = [
+			"tiborvass",
+			"tonistiigi",
+		]
+
+	[Org.Curators]
+
+	# The curators help ensure that incoming issues and pull requests are properly triaged and
+	# that our various contribution and reviewing processes are respected. With their knowledge of
+	# the repository activity, they can also guide contributors to relevant material or
+	# discussions.
+	#
+	# They are neither code nor docs reviewers, so they are never expected to merge. They can
+	# however:
+	# - close an issue or pull request when it's an exact duplicate
+	# - close an issue or pull request when it's inappropriate or off-topic
+
+		people = [
+			"thajeztah",
+		]
+
+[people]
+
+# A reference list of all people associated with the project.
+# All other sections should refer to people by their canonical key
+# in the people section.
+
+	[people.thajeztah]
+	Name = "Sebastiaan van Stijn"
+	Email = "[email protected]"
+	GitHub = "thaJeztah"
+
+	[people.tiborvass]
+	Name = "Tibor Vass"
+	Email = "[email protected]"
+	GitHub = "tiborvass"
+
+	[people.tonistiigi]
+	Name = "Tõnis Tiigi"
+	Email = "[email protected]"
+	GitHub = "tonistiigi"

Makefile

@@ -25,4 +25,7 @@ validate-all: lint test validate-vendor
 vendor:
 	./hack/update-vendor
 
-.PHONY: vendor lint shell binaries install binaries-cross validate-all
+generate-authors:
+	./hack/generate-authors
+
+.PHONY: vendor lint shell binaries install binaries-cross validate-all generate-authors

hack/generate-authors

@@ -0,0 +1,21 @@
+#!/usr/bin/env bash
+
+set -eu -o pipefail -x
+
+if [ -x "$(command -v greadlink)" ]; then
+	# on macOS, GNU readlink is ava (greadlink) can be installed through brew install coreutils
+	cd "$(dirname "$(greadlink -f "$BASH_SOURCE")")/.."
+else
+	cd "$(dirname "$(readlink -f "$BASH_SOURCE")")/.."
+fi
+
+# see also ".mailmap" for how email addresses and names are deduplicated
+
+{
+	cat <<-'EOH'
+	# This file lists all individuals having contributed content to the repository.
+	# For how it is generated, see `scripts/generate-authors.sh`.
+	EOH
+	echo
+	git log --format='%aN <%aE>' | LC_ALL=C.UTF-8 sort -uf
+} > AUTHORS