diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000000..8f8a6218a7 --- /dev/null +++ b/.gitignore @@ -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 diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 0000000000..5ccf65ed26 --- /dev/null +++ b/Dockerfile @@ -0,0 +1,34 @@ +FROM alpine +MAINTAINER Jessica Frazelle + +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" ] diff --git a/MAINTAINERS b/MAINTAINERS new file mode 100755 index 0000000000..68b76b1373 --- /dev/null +++ b/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" diff --git a/Makefile b/Makefile new file mode 100644 index 0000000000..84cbe0ba70 --- /dev/null +++ b/Makefile @@ -0,0 +1,5 @@ +.PHONY: maintainers + +maintainers: + @docker build --rm --force-rm -t docker/maintainers . + @docker run --rm -v $(CURDIR):/root/maintainers docker/maintainers diff --git a/maintainers/generate.go b/maintainers/generate.go new file mode 100644 index 0000000000..ded6bb3a12 --- /dev/null +++ b/maintainers/generate.go @@ -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 +} diff --git a/maintainers/main.go b/maintainers/main.go new file mode 100644 index 0000000000..1639505b2a --- /dev/null +++ b/maintainers/main.go @@ -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 +} diff --git a/maintainers/roles.toml b/maintainers/roles.toml new file mode 100644 index 0000000000..b4e02026e4 --- /dev/null +++ b/maintainers/roles.toml @@ -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. +""" + + diff --git a/maintainers/rules.toml b/maintainers/rules.toml new file mode 100644 index 0000000000..61df17abe7 --- /dev/null +++ b/maintainers/rules.toml @@ -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 :)" + + diff --git a/maintainers/types.go b/maintainers/types.go new file mode 100644 index 0000000000..ec56a9780a --- /dev/null +++ b/maintainers/types.go @@ -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"` +}