mirror of https://github.com/docker/docs.git
inital parsing of maintainers files
Signed-off-by: Jessica Frazelle <acidburn@docker.com>
This commit is contained in:
Jessica Frazelle
parent
cf011bc1cb
commit
57e15b3c66
|
|
@ -0,0 +1,53 @@
|
||||||
|
###Go###
|
||||||
|
|
||||||
|
# Compiled Object files, Static and Dynamic libs (Shared Objects)
|
||||||
|
*.o
|
||||||
|
*.a
|
||||||
|
*.so
|
||||||
|
*.swo
|
||||||
|
*.swp
|
||||||
|
|
||||||
|
# Folders
|
||||||
|
_obj
|
||||||
|
_test
|
||||||
|
|
||||||
|
# Architecture specific extensions/prefixes
|
||||||
|
*.[568vq]
|
||||||
|
[568vq].out
|
||||||
|
|
||||||
|
*.cgo1.go
|
||||||
|
*.cgo2.c
|
||||||
|
_cgo_defun.c
|
||||||
|
_cgo_gotypes.go
|
||||||
|
_cgo_export.*
|
||||||
|
|
||||||
|
_testmain.go
|
||||||
|
|
||||||
|
*.exe
|
||||||
|
*.test
|
||||||
|
|
||||||
|
|
||||||
|
###OSX###
|
||||||
|
|
||||||
|
.DS_Store
|
||||||
|
.AppleDouble
|
||||||
|
.LSOverride
|
||||||
|
|
||||||
|
# Icon must ends with two \r.
|
||||||
|
Icon
|
||||||
|
|
||||||
|
|
||||||
|
# Thumbnails
|
||||||
|
._*
|
||||||
|
Thumb.db
|
||||||
|
|
||||||
|
# Files that might appear on external disk
|
||||||
|
.Spotlight-V100
|
||||||
|
.Trashes
|
||||||
|
|
||||||
|
maintainers/maintainers
|
||||||
|
maintainers/MAINTAINERS
|
||||||
|
|
||||||
|
# go generated files
|
||||||
|
maintainers/rules.go
|
||||||
|
maintainers/roles.go
|
||||||
|
|
@ -0,0 +1,34 @@
|
||||||
|
FROM alpine
|
||||||
|
MAINTAINER Jessica Frazelle <jess@docker.com>
|
||||||
|
|
||||||
|
ENV PATH /go/bin:/usr/local/go/bin:$PATH
|
||||||
|
ENV GOPATH /go
|
||||||
|
|
||||||
|
RUN apk update && apk add \
|
||||||
|
ca-certificates \
|
||||||
|
&& rm -rf /var/cache/apk/*
|
||||||
|
|
||||||
|
COPY . /go/src/github.com/docker/opensource
|
||||||
|
|
||||||
|
RUN buildDeps=' \
|
||||||
|
go \
|
||||||
|
git \
|
||||||
|
gcc \
|
||||||
|
libc-dev \
|
||||||
|
libgcc \
|
||||||
|
' \
|
||||||
|
set -x \
|
||||||
|
&& apk update \
|
||||||
|
&& apk add $buildDeps \
|
||||||
|
&& cd /go/src/github.com/docker/opensource \
|
||||||
|
&& go get -d -v github.com/docker/opensource/maintainers \
|
||||||
|
&& go generate ./maintainers \
|
||||||
|
&& go build -o /usr/bin/maintainers ./maintainers \
|
||||||
|
&& apk del $buildDeps \
|
||||||
|
&& rm -rf /var/cache/apk/* \
|
||||||
|
&& rm -rf /go \
|
||||||
|
&& echo "Build complete."
|
||||||
|
|
||||||
|
WORKDIR /root/maintainers
|
||||||
|
|
||||||
|
ENTRYPOINT [ "maintainers" ]
|
||||||
|
|
@ -0,0 +1,397 @@
|
||||||
|
#
|
||||||
|
# THIS FILE IS AUTOGENERATED; SEE "./maintainers"!
|
||||||
|
#
|
||||||
|
# Docker projects maintainers file
|
||||||
|
#
|
||||||
|
# This file describes who runs the Docker project and how.
|
||||||
|
# This is a living document - if you see something out of date or missing,
|
||||||
|
# speak up!
|
||||||
|
#
|
||||||
|
# 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.bdfl]
|
||||||
|
|
||||||
|
title = "The Benevolent dictator for life (BDFL)"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
Docker follows the timeless, highly efficient and totally unfair system
|
||||||
|
known as [Benevolent dictator for
|
||||||
|
life](https://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with
|
||||||
|
yours truly, Solomon Hykes, in the role of BDFL. This means that all
|
||||||
|
decisions are made, by default, by Solomon. Since making every decision
|
||||||
|
myself would be highly un-scalable, in practice decisions are spread
|
||||||
|
across multiple maintainers.
|
||||||
|
|
||||||
|
Ideally, the BDFL role is like the Queen of England: awesome crown, but not
|
||||||
|
an actual operational role day-to-day. The real job of a BDFL is to NEVER GO AWAY.
|
||||||
|
Every other rule can change, perhaps drastically so, but the BDFL will always
|
||||||
|
be there, preserving the philosophy and principles of the project, and keeping
|
||||||
|
ultimate authority over its fate. This gives us great flexibility in experimenting
|
||||||
|
with various governance models, knowing that we can always press the "reset" button
|
||||||
|
without fear of fragmentation or deadlock. See the US congress for a counter-example.
|
||||||
|
|
||||||
|
BDFL daily routine:
|
||||||
|
|
||||||
|
* Is the project governance stuck in a deadlock or irreversibly fragmented?
|
||||||
|
* If yes: refactor the project governance
|
||||||
|
* Are there issues or conflicts escalated by core?
|
||||||
|
* If yes: resolve them
|
||||||
|
* Go back to polishing that crown.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Rules.decisions]
|
||||||
|
|
||||||
|
title = "How are decisions made?"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
Short answer: EVERYTHING IS A PULL REQUEST.
|
||||||
|
|
||||||
|
Docker 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 Docker, 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. See *review flow*
|
||||||
|
for details.
|
||||||
|
|
||||||
|
Because Docker is such a large and active project, it's important for everyone to know
|
||||||
|
who is responsible for deciding what. That is determined by a precise set of rules.
|
||||||
|
|
||||||
|
* For every *decision* in the project, the rules should designate, in a deterministic way,
|
||||||
|
who should *decide*.
|
||||||
|
|
||||||
|
* For every *problem* in the project, the rules should designate, in a deterministic way,
|
||||||
|
who should be responsible for *fixing* it.
|
||||||
|
|
||||||
|
* For every *question* in the project, the rules should designate, in a deterministic way,
|
||||||
|
who should be expected to have the *answer*.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Rules.review]
|
||||||
|
|
||||||
|
title = "Review flow"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
Pull requests should be processed according to the following flow:
|
||||||
|
|
||||||
|
* For each subsystem affected by the change, the maintainers of the subsystem must approve or refuse it.
|
||||||
|
It is the responsibility of the subsystem maintainers to process patches affecting them in a timely
|
||||||
|
manner.
|
||||||
|
|
||||||
|
* If the change affects areas of the code which are not part of a subsystem,
|
||||||
|
or if subsystem maintainers are unable to reach a timely decision, it must be approved by
|
||||||
|
the core maintainers.
|
||||||
|
|
||||||
|
* If the change affects the UI or public APIs, or if it represents a major change in architecture,
|
||||||
|
the architects must approve or refuse it.
|
||||||
|
|
||||||
|
* If the change affects the operations of the project, it must be approved or rejected by
|
||||||
|
the relevant operators.
|
||||||
|
|
||||||
|
* If the change affects the governance, philosophy, goals or principles of the project,
|
||||||
|
it must be approved by BDFL.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Rules.DCO]
|
||||||
|
|
||||||
|
title = "Helping contributors with the DCO"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
The [DCO or `Sign your work`](
|
||||||
|
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work)
|
||||||
|
requirement is not intended as a roadblock or speed bump.
|
||||||
|
|
||||||
|
Some Docker 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.holiday]
|
||||||
|
|
||||||
|
title = "I'm a maintainer, and I'm going on holiday"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
Please let your co-maintainers and other contributors know by raising a pull
|
||||||
|
request that comments out your `MAINTAINERS` file entry using a `#`.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[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 :)"
|
||||||
|
|
||||||
|
|
||||||
|
# Current project roles
|
||||||
|
[Roles]
|
||||||
|
|
||||||
|
[Roles.bdfl]
|
||||||
|
|
||||||
|
person = "shykes"
|
||||||
|
|
||||||
|
[Roles."Chief Architect"]
|
||||||
|
|
||||||
|
person = "shykes"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
The chief architect is responsible for the overall integrity of the technical architecture
|
||||||
|
across all subsystems, and the consistency of APIs and UI.
|
||||||
|
|
||||||
|
Changes to UI, public APIs and overall architecture (for example a plugin system) must
|
||||||
|
be approved by the chief architect.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Roles."Chief Maintainer"]
|
||||||
|
|
||||||
|
person = "crosbymichael"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
The chief maintainer is responsible for all aspects of quality for the project including
|
||||||
|
code reviews, usability, stability, security, performance, etc.
|
||||||
|
The most important function of the chief maintainer is to lead by example. On the first
|
||||||
|
day of a new maintainer, the best advice should be "follow the C.M.'s example and you'll
|
||||||
|
be fine".
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Roles."Community Manager"]
|
||||||
|
|
||||||
|
person = "theadactyl"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
The community manager is responsible for serving the project community, including users,
|
||||||
|
contributors and partners. This involves:
|
||||||
|
- facilitating communication between maintainers, contributors and users
|
||||||
|
- organizing contributor and maintainer events
|
||||||
|
- helping new contributors get involved
|
||||||
|
- anything the project community needs to be successful
|
||||||
|
|
||||||
|
The community manager is a point of contact for any contributor who has questions, concerns
|
||||||
|
or feedback about project operations.
|
||||||
|
"""
|
||||||
|
|
||||||
|
|
||||||
|
[Org]
|
||||||
|
[Org.Curators]
|
||||||
|
People = ["thajeztah"]
|
||||||
|
[Org."Docs maintainers"]
|
||||||
|
People = ["jamtur01", "moxiegirl", "sven", "thajeztah"]
|
||||||
|
[Org.compose]
|
||||||
|
People = ["aanand", "bfirsh", "dnephin", "mnowster"]
|
||||||
|
[Org.docker]
|
||||||
|
People = ["calavera", "cpuguy83", "crosbymichael", "duglin", "erikh", "estesp", "icecrime", "jfrazelle", "lk4d4", "runcom", "tianon", "tibor", "unclejack", "vbatts", "vdemeester", "vieux", "vishh"]
|
||||||
|
[Org.libcompose]
|
||||||
|
People = ["aanand", "aduermael", "dnephin", "ibuildthecloud", "gdevillele", "vdemeester"]
|
||||||
|
[Org.machine]
|
||||||
|
People = ["dgageot", "ehazlett", "jeanlaurent", "nathanleclaire"]
|
||||||
|
[Org.notary]
|
||||||
|
People = ["cyli", "diogomonica", "dmcgowan", "endophage", "nathanmccauley"]
|
||||||
|
|
||||||
|
[People]
|
||||||
|
[People.aanand]
|
||||||
|
Name = "Aanand Prasad"
|
||||||
|
Email = "aanand@docker.com"
|
||||||
|
GitHub = "aanand"
|
||||||
|
[People.aduermael]
|
||||||
|
Name = "Adrien Duermael"
|
||||||
|
Email = "adrien@docker.com"
|
||||||
|
GitHub = "aduermael"
|
||||||
|
[People.bfirsh]
|
||||||
|
Name = "Ben Firshman"
|
||||||
|
Email = "ben@firshman.co.uk"
|
||||||
|
GitHub = "bfirsh"
|
||||||
|
[People.calavera]
|
||||||
|
Name = "David Calavera"
|
||||||
|
Email = "david.calavera@gmail.com"
|
||||||
|
GitHub = "calavera"
|
||||||
|
[People.cpuguy83]
|
||||||
|
Name = "Brian Goff"
|
||||||
|
Email = "cpuguy83@gmail.com"
|
||||||
|
GitHub = "cpuguy83"
|
||||||
|
[People.crosbymichael]
|
||||||
|
Name = "Michael Crosby"
|
||||||
|
Email = "crosbymichael@gmail.com"
|
||||||
|
GitHub = "crosbymichael"
|
||||||
|
[People.cyli]
|
||||||
|
Name = "Ying Li"
|
||||||
|
Email = "ying.li@docker.com"
|
||||||
|
GitHub = "cyli"
|
||||||
|
[People.dgageot]
|
||||||
|
Name = "David Gageot"
|
||||||
|
Email = "david.gageot@docker.com"
|
||||||
|
GitHub = "dgageot"
|
||||||
|
[People.diogomonica]
|
||||||
|
Name = "Diogo Monica"
|
||||||
|
Email = "diogo@docker.com"
|
||||||
|
GitHub = "diogomonica"
|
||||||
|
[People.dmcgowan]
|
||||||
|
Name = "Derek McGowan"
|
||||||
|
Email = "derek@docker.com"
|
||||||
|
GitHub = "dmcgowan"
|
||||||
|
[People.dnephin]
|
||||||
|
Name = "Daniel Nephin"
|
||||||
|
Email = "dnephin@gmail.com"
|
||||||
|
GitHub = "dnephin"
|
||||||
|
[People.duglin]
|
||||||
|
Name = "Doug Davis"
|
||||||
|
Email = "dug@us.ibm.com"
|
||||||
|
GitHub = "duglin"
|
||||||
|
[People.ehazlett]
|
||||||
|
Name = "Evan Hazlett"
|
||||||
|
Email = "ejhazlett@gmail.com"
|
||||||
|
GitHub = "ehazlett"
|
||||||
|
[People.endophage]
|
||||||
|
Name = "David Lawrence"
|
||||||
|
Email = "david.lawrence@docker.com"
|
||||||
|
GitHub = "endophage"
|
||||||
|
[People.erikh]
|
||||||
|
Name = "Erik Hollensbe"
|
||||||
|
Email = "erik@docker.com"
|
||||||
|
GitHub = "erikh"
|
||||||
|
[People.estesp]
|
||||||
|
Name = "Phil Estes"
|
||||||
|
Email = "estesp@linux.vnet.ibm.com"
|
||||||
|
GitHub = "estesp"
|
||||||
|
[People.gdevillele]
|
||||||
|
Name = "Gaetan de Villele"
|
||||||
|
Email = "gaetan@docker.com"
|
||||||
|
GitHub = "gdevillele"
|
||||||
|
[People.ibuildthecloud]
|
||||||
|
Name = "Darren Shepherd"
|
||||||
|
Email = "darren@rancher.com"
|
||||||
|
GitHub = "ibuildthecloud"
|
||||||
|
[People.icecrime]
|
||||||
|
Name = "Arnaud Porterie"
|
||||||
|
Email = "arnaud@docker.com"
|
||||||
|
GitHub = "icecrime"
|
||||||
|
[People.jamtur01]
|
||||||
|
Name = "James Turnbull"
|
||||||
|
Email = "james@lovedthanlost.net"
|
||||||
|
GitHub = "jamtur01"
|
||||||
|
[People.jeanlaurent]
|
||||||
|
Name = "Jean-Laurent de Morlhon"
|
||||||
|
Email = "jeanlaurent@docker.com>"
|
||||||
|
GitHub = "jeanlaurent"
|
||||||
|
[People.jfrazelle]
|
||||||
|
Name = "Jessie Frazelle"
|
||||||
|
Email = "j@docker.com"
|
||||||
|
GitHub = "jfrazelle"
|
||||||
|
[People.lk4d4]
|
||||||
|
Name = "Alexander Morozov"
|
||||||
|
Email = "lk4d4@docker.com"
|
||||||
|
GitHub = "lk4d4"
|
||||||
|
[People.mnowster]
|
||||||
|
Name = "Mazz Mosley"
|
||||||
|
Email = "mazz@houseofmnowster.com"
|
||||||
|
GitHub = "mnowster"
|
||||||
|
[People.moxiegirl]
|
||||||
|
Name = "Mary Anthony"
|
||||||
|
Email = "mary.anthony@docker.com"
|
||||||
|
GitHub = "moxiegirl"
|
||||||
|
[People.nathanleclaire]
|
||||||
|
Name = "Nathan LeClaire"
|
||||||
|
Email = "nathan.leclaire@docker.com"
|
||||||
|
GitHub = "nathanleclaire"
|
||||||
|
[People.nathanmccauley]
|
||||||
|
Name = "Nathan McCauley"
|
||||||
|
Email = "nathan.mccauley@docker.com"
|
||||||
|
GitHub = "nathanmccauley"
|
||||||
|
[People.runcom]
|
||||||
|
Name = "Antonio Murdaca"
|
||||||
|
Email = "me@runcom.ninja"
|
||||||
|
GitHub = "runcom"
|
||||||
|
[People.shykes]
|
||||||
|
Name = "Solomon Hykes"
|
||||||
|
Email = "solomon@docker.com"
|
||||||
|
GitHub = "shykes"
|
||||||
|
[People.sven]
|
||||||
|
Name = "Sven Dowideit"
|
||||||
|
Email = "SvenDowideit@home.org.au"
|
||||||
|
GitHub = "SvenDowideit"
|
||||||
|
[People.thajeztah]
|
||||||
|
Name = "Sebastiaan van Stijn"
|
||||||
|
Email = "github@gone.nl"
|
||||||
|
GitHub = "thaJeztah"
|
||||||
|
[People.theadactyl]
|
||||||
|
Name = "Thea Lamkin"
|
||||||
|
Email = "thea@docker.com"
|
||||||
|
GitHub = "theadactyl"
|
||||||
|
[People.tianon]
|
||||||
|
Name = "Tianon Gravi"
|
||||||
|
Email = "admwiggin@gmail.com"
|
||||||
|
GitHub = "tianon"
|
||||||
|
[People.tibor]
|
||||||
|
Name = "Tibor Vass"
|
||||||
|
Email = "tibor@docker.com"
|
||||||
|
GitHub = "tiborvass"
|
||||||
|
[People.unclejack]
|
||||||
|
Name = "Cristian Staretu"
|
||||||
|
Email = "cristian.staretu@gmail.com"
|
||||||
|
GitHub = "unclejack"
|
||||||
|
[People.vbatts]
|
||||||
|
Name = "Vincent Batts"
|
||||||
|
Email = "vbatts@redhat.com"
|
||||||
|
GitHub = "vbatts"
|
||||||
|
[People.vdemeester]
|
||||||
|
Name = "Vincent Demeester"
|
||||||
|
Email = "vincent@sbr.pm"
|
||||||
|
GitHub = "vdemeester"
|
||||||
|
[People.vieux]
|
||||||
|
Name = "Victor Vieux"
|
||||||
|
Email = "vieux@docker.com"
|
||||||
|
GitHub = "vieux"
|
||||||
|
[People.vishh]
|
||||||
|
Name = "Vishnu Kannan"
|
||||||
|
Email = "vishnuk@google.com"
|
||||||
|
GitHub = "vishh"
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
.PHONY: maintainers
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
@docker build --rm --force-rm -t docker/maintainers .
|
||||||
|
@docker run --rm -v $(CURDIR):/root/maintainers docker/maintainers
|
||||||
|
|
@ -0,0 +1,43 @@
|
||||||
|
// +build ignore
|
||||||
|
|
||||||
|
package main
|
||||||
|
|
||||||
|
import (
|
||||||
|
"fmt"
|
||||||
|
"io/ioutil"
|
||||||
|
"os"
|
||||||
|
"path/filepath"
|
||||||
|
)
|
||||||
|
|
||||||
|
func main() {
|
||||||
|
wd, err := os.Getwd()
|
||||||
|
if err != nil {
|
||||||
|
panic(err)
|
||||||
|
}
|
||||||
|
|
||||||
|
if err := generateFile(wd, "rules.toml", "rules"); err != nil {
|
||||||
|
panic(err)
|
||||||
|
}
|
||||||
|
|
||||||
|
if err := generateFile(wd, "roles.toml", "roles"); err != nil {
|
||||||
|
panic(err)
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
func generateFile(wd string, file string, target string) error {
|
||||||
|
src, err := ioutil.ReadFile(file)
|
||||||
|
if err != nil {
|
||||||
|
panic(err)
|
||||||
|
}
|
||||||
|
out, err := os.Create(filepath.Join(wd, target+".go"))
|
||||||
|
if err != nil {
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
out.Write([]byte("// This file is autogenerated; DO NOT EDIT DIRECTLY\n// See maintainers/generate.go for more info\npackage main\n\nconst (\n"))
|
||||||
|
|
||||||
|
out.Write([]byte(fmt.Sprintf("%s = %q", target, string(src))))
|
||||||
|
|
||||||
|
out.Write([]byte("\n)\n"))
|
||||||
|
|
||||||
|
return nil
|
||||||
|
}
|
||||||
|
|
@ -0,0 +1,132 @@
|
||||||
|
package main
|
||||||
|
|
||||||
|
import (
|
||||||
|
"bytes"
|
||||||
|
"fmt"
|
||||||
|
"io/ioutil"
|
||||||
|
"net/http"
|
||||||
|
"strings"
|
||||||
|
|
||||||
|
"github.com/BurntSushi/toml"
|
||||||
|
"github.com/Sirupsen/logrus"
|
||||||
|
)
|
||||||
|
|
||||||
|
const (
|
||||||
|
ghRawUri = "https://raw.githubusercontent.com"
|
||||||
|
head = `#
|
||||||
|
# THIS FILE IS AUTOGENERATED; SEE "./maintainers"!
|
||||||
|
#
|
||||||
|
# Docker projects maintainers file
|
||||||
|
#
|
||||||
|
# This file describes who runs the Docker project and how.
|
||||||
|
# This is a living document - if you see something out of date or missing,
|
||||||
|
# speak up!
|
||||||
|
#
|
||||||
|
# It is structured to be consumable by both humans and programs.
|
||||||
|
# To extract its contents programmatically, use any TOML-compliant
|
||||||
|
# parser.
|
||||||
|
`
|
||||||
|
)
|
||||||
|
|
||||||
|
var (
|
||||||
|
org = "docker"
|
||||||
|
projects = []string{
|
||||||
|
"compose",
|
||||||
|
"distribution",
|
||||||
|
"docker",
|
||||||
|
"dockercraft",
|
||||||
|
"kitematic",
|
||||||
|
"libcompose",
|
||||||
|
"libnetwork",
|
||||||
|
"machine",
|
||||||
|
"notary",
|
||||||
|
"swarm",
|
||||||
|
"toolbox",
|
||||||
|
}
|
||||||
|
)
|
||||||
|
|
||||||
|
//go:generate go run generate.go
|
||||||
|
|
||||||
|
func main() {
|
||||||
|
// initialize the project MAINTAINERS file
|
||||||
|
projectMaintainers := Maintainers{
|
||||||
|
Org: map[string]*Org{},
|
||||||
|
People: map[string]Person{},
|
||||||
|
}
|
||||||
|
|
||||||
|
// parse the MAINTAINERS file for each repo
|
||||||
|
for _, project := range projects {
|
||||||
|
maintainers, err := getMaintainers(project)
|
||||||
|
if err != nil {
|
||||||
|
logrus.Errorf("%s: parsing MAINTAINERS file failed: %v", project, err)
|
||||||
|
continue
|
||||||
|
}
|
||||||
|
|
||||||
|
// create the Org object for the project
|
||||||
|
p := &Org{
|
||||||
|
// Repo: fmt.Sprintf("https://github.com/%s/%s", org, project),
|
||||||
|
// TODO: change this to:
|
||||||
|
// People: maintainers.Org["Core maintainers"].People,
|
||||||
|
// once MaintainersDepreciated is removed.
|
||||||
|
People: maintainers.Organization.CoreMaintainers.People,
|
||||||
|
}
|
||||||
|
|
||||||
|
// lowercase all maintainers nicks for consistency
|
||||||
|
for i, n := range p.People {
|
||||||
|
p.People[i] = strings.ToLower(n)
|
||||||
|
}
|
||||||
|
|
||||||
|
projectMaintainers.Org[project] = p
|
||||||
|
|
||||||
|
if maintainers.Organization.DocsMaintainers != nil {
|
||||||
|
projectMaintainers.Org["Docs maintainers"] = maintainers.Organization.DocsMaintainers
|
||||||
|
}
|
||||||
|
|
||||||
|
if maintainers.Organization.Curators != nil {
|
||||||
|
projectMaintainers.Org["Curators"] = maintainers.Organization.Curators
|
||||||
|
}
|
||||||
|
|
||||||
|
// iterate through the people and add them to compiled list
|
||||||
|
for nick, person := range maintainers.People {
|
||||||
|
projectMaintainers.People[strings.ToLower(nick)] = person
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
// encode the result to a file
|
||||||
|
buf := new(bytes.Buffer)
|
||||||
|
t := toml.NewEncoder(buf)
|
||||||
|
t.Indent = " "
|
||||||
|
if err := t.Encode(projectMaintainers); err != nil {
|
||||||
|
logrus.Fatalf("TOML encoding error: %v", err)
|
||||||
|
}
|
||||||
|
|
||||||
|
file := append([]byte(head), []byte(rules)...)
|
||||||
|
file = append(file, []byte(roles)...)
|
||||||
|
file = append(file, buf.Bytes()...)
|
||||||
|
|
||||||
|
if err := ioutil.WriteFile("MAINTAINERS", file, 0755); err != nil {
|
||||||
|
logrus.Fatal(err)
|
||||||
|
}
|
||||||
|
|
||||||
|
logrus.Infof("Successfully wrote new combined MAINTAINERS file.")
|
||||||
|
}
|
||||||
|
|
||||||
|
func getMaintainers(project string) (maintainers MaintainersDepreciated, err error) {
|
||||||
|
fileUrl := fmt.Sprintf("%s/%s/%s/master/MAINTAINERS", ghRawUri, org, project)
|
||||||
|
resp, err := http.Get(fileUrl)
|
||||||
|
if err != nil {
|
||||||
|
return maintainers, fmt.Errorf("%s: %v", project, err)
|
||||||
|
}
|
||||||
|
defer resp.Body.Close()
|
||||||
|
|
||||||
|
file, err := ioutil.ReadAll(resp.Body)
|
||||||
|
if err != nil {
|
||||||
|
return maintainers, fmt.Errorf("%s: %v", project, err)
|
||||||
|
}
|
||||||
|
|
||||||
|
if _, err := toml.Decode(string(file), &maintainers); err != nil {
|
||||||
|
return maintainers, fmt.Errorf("%s: parsing MAINTAINERS file failed: %v", project, err)
|
||||||
|
}
|
||||||
|
|
||||||
|
return maintainers, nil
|
||||||
|
}
|
||||||
|
|
@ -0,0 +1,48 @@
|
||||||
|
# Current project roles
|
||||||
|
[Roles]
|
||||||
|
|
||||||
|
[Roles.bdfl]
|
||||||
|
|
||||||
|
person = "shykes"
|
||||||
|
|
||||||
|
[Roles."Chief Architect"]
|
||||||
|
|
||||||
|
person = "shykes"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
The chief architect is responsible for the overall integrity of the technical architecture
|
||||||
|
across all subsystems, and the consistency of APIs and UI.
|
||||||
|
|
||||||
|
Changes to UI, public APIs and overall architecture (for example a plugin system) must
|
||||||
|
be approved by the chief architect.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Roles."Chief Maintainer"]
|
||||||
|
|
||||||
|
person = "crosbymichael"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
The chief maintainer is responsible for all aspects of quality for the project including
|
||||||
|
code reviews, usability, stability, security, performance, etc.
|
||||||
|
The most important function of the chief maintainer is to lead by example. On the first
|
||||||
|
day of a new maintainer, the best advice should be "follow the C.M.'s example and you'll
|
||||||
|
be fine".
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Roles."Community Manager"]
|
||||||
|
|
||||||
|
person = "theadactyl"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
The community manager is responsible for serving the project community, including users,
|
||||||
|
contributors and partners. This involves:
|
||||||
|
- facilitating communication between maintainers, contributors and users
|
||||||
|
- organizing contributor and maintainer events
|
||||||
|
- helping new contributors get involved
|
||||||
|
- anything the project community needs to be successful
|
||||||
|
|
||||||
|
The community manager is a point of contact for any contributor who has questions, concerns
|
||||||
|
or feedback about project operations.
|
||||||
|
"""
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -0,0 +1,164 @@
|
||||||
|
[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.bdfl]
|
||||||
|
|
||||||
|
title = "The Benevolent dictator for life (BDFL)"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
Docker follows the timeless, highly efficient and totally unfair system
|
||||||
|
known as [Benevolent dictator for
|
||||||
|
life](https://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with
|
||||||
|
yours truly, Solomon Hykes, in the role of BDFL. This means that all
|
||||||
|
decisions are made, by default, by Solomon. Since making every decision
|
||||||
|
myself would be highly un-scalable, in practice decisions are spread
|
||||||
|
across multiple maintainers.
|
||||||
|
|
||||||
|
Ideally, the BDFL role is like the Queen of England: awesome crown, but not
|
||||||
|
an actual operational role day-to-day. The real job of a BDFL is to NEVER GO AWAY.
|
||||||
|
Every other rule can change, perhaps drastically so, but the BDFL will always
|
||||||
|
be there, preserving the philosophy and principles of the project, and keeping
|
||||||
|
ultimate authority over its fate. This gives us great flexibility in experimenting
|
||||||
|
with various governance models, knowing that we can always press the "reset" button
|
||||||
|
without fear of fragmentation or deadlock. See the US congress for a counter-example.
|
||||||
|
|
||||||
|
BDFL daily routine:
|
||||||
|
|
||||||
|
* Is the project governance stuck in a deadlock or irreversibly fragmented?
|
||||||
|
* If yes: refactor the project governance
|
||||||
|
* Are there issues or conflicts escalated by core?
|
||||||
|
* If yes: resolve them
|
||||||
|
* Go back to polishing that crown.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Rules.decisions]
|
||||||
|
|
||||||
|
title = "How are decisions made?"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
Short answer: EVERYTHING IS A PULL REQUEST.
|
||||||
|
|
||||||
|
Docker 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 Docker, 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. See *review flow*
|
||||||
|
for details.
|
||||||
|
|
||||||
|
Because Docker is such a large and active project, it's important for everyone to know
|
||||||
|
who is responsible for deciding what. That is determined by a precise set of rules.
|
||||||
|
|
||||||
|
* For every *decision* in the project, the rules should designate, in a deterministic way,
|
||||||
|
who should *decide*.
|
||||||
|
|
||||||
|
* For every *problem* in the project, the rules should designate, in a deterministic way,
|
||||||
|
who should be responsible for *fixing* it.
|
||||||
|
|
||||||
|
* For every *question* in the project, the rules should designate, in a deterministic way,
|
||||||
|
who should be expected to have the *answer*.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Rules.review]
|
||||||
|
|
||||||
|
title = "Review flow"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
Pull requests should be processed according to the following flow:
|
||||||
|
|
||||||
|
* For each subsystem affected by the change, the maintainers of the subsystem must approve or refuse it.
|
||||||
|
It is the responsibility of the subsystem maintainers to process patches affecting them in a timely
|
||||||
|
manner.
|
||||||
|
|
||||||
|
* If the change affects areas of the code which are not part of a subsystem,
|
||||||
|
or if subsystem maintainers are unable to reach a timely decision, it must be approved by
|
||||||
|
the core maintainers.
|
||||||
|
|
||||||
|
* If the change affects the UI or public APIs, or if it represents a major change in architecture,
|
||||||
|
the architects must approve or refuse it.
|
||||||
|
|
||||||
|
* If the change affects the operations of the project, it must be approved or rejected by
|
||||||
|
the relevant operators.
|
||||||
|
|
||||||
|
* If the change affects the governance, philosophy, goals or principles of the project,
|
||||||
|
it must be approved by BDFL.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[Rules.DCO]
|
||||||
|
|
||||||
|
title = "Helping contributors with the DCO"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
The [DCO or `Sign your work`](
|
||||||
|
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work)
|
||||||
|
requirement is not intended as a roadblock or speed bump.
|
||||||
|
|
||||||
|
Some Docker 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.holiday]
|
||||||
|
|
||||||
|
title = "I'm a maintainer, and I'm going on holiday"
|
||||||
|
|
||||||
|
text = """
|
||||||
|
Please let your co-maintainers and other contributors know by raising a pull
|
||||||
|
request that comments out your `MAINTAINERS` file entry using a `#`.
|
||||||
|
"""
|
||||||
|
|
||||||
|
[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 :)"
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -0,0 +1,54 @@
|
||||||
|
package main
|
||||||
|
|
||||||
|
// Maintainers defines the struct for a MAINTAINERS file
|
||||||
|
type Maintainers struct {
|
||||||
|
Rules map[string]Rule
|
||||||
|
Roles map[string]Role
|
||||||
|
Org map[string]*Org
|
||||||
|
People map[string]Person
|
||||||
|
}
|
||||||
|
|
||||||
|
// Rule is a project rule
|
||||||
|
type Rule struct {
|
||||||
|
Title string `toml:"title,omitempty"`
|
||||||
|
Text string `toml:"text,omitempty"`
|
||||||
|
}
|
||||||
|
|
||||||
|
// Role is a project role
|
||||||
|
type Role struct {
|
||||||
|
Person string `toml:"person,omitempty"`
|
||||||
|
Text string `toml:"text,omitempty"`
|
||||||
|
}
|
||||||
|
|
||||||
|
// Org defines the organization within a project
|
||||||
|
type Org struct {
|
||||||
|
People []string
|
||||||
|
}
|
||||||
|
|
||||||
|
// Person member of the project
|
||||||
|
type Person struct {
|
||||||
|
Name string
|
||||||
|
Email string
|
||||||
|
GitHub string
|
||||||
|
}
|
||||||
|
|
||||||
|
// MaintainersDepreciated is an old struct for compatibility
|
||||||
|
// with the docker/docker maintainers file.
|
||||||
|
// TODO: delete this once the file in docker/docker repo is updated
|
||||||
|
type MaintainersDepreciated struct {
|
||||||
|
Rules map[string]Rule
|
||||||
|
Organization Organization `toml:"Org"`
|
||||||
|
People map[string]Person
|
||||||
|
}
|
||||||
|
|
||||||
|
// Organization defines the project's organization
|
||||||
|
// TODO: delete this once MaintainersDepreciated is removed
|
||||||
|
type Organization struct {
|
||||||
|
BDFL string `toml:"bdfl"`
|
||||||
|
ChiefArchitect string `toml:"Chief Architect"`
|
||||||
|
ChiefMaintainer string `toml:"Chief Maintainer"`
|
||||||
|
CommunityManager string `toml:"Community Manager"`
|
||||||
|
CoreMaintainers *Org `toml:"Core maintainers"`
|
||||||
|
DocsMaintainers *Org `toml:"Docs maintainers"`
|
||||||
|
Curators *Org `toml:"Curators"`
|
||||||
|
}
|
||||||
Loading…
Reference in New Issue