Merge pull request #85 from tiborvass/license-contributing
Add project files (LICENSE, AUTHORS, MAINTAINERS, Code of Conduct, CONTRIBUTING)pull/86/head
Tõnis Tiigi
6 years ago
committed by
GitHub
commit
8b6dfbd9c8
@ -0,0 +1,4 @@
|
|||||||
|
# Code of conduct
|
||||||
|
|
||||||
|
- [Moby community guidelines](https://github.com/moby/moby/blob/master/CONTRIBUTING.md#moby-community-guidelines)
|
||||||
|
- [Docker Code of Conduct](https://github.com/docker/code-of-conduct)
|
||||||
@ -0,0 +1,292 @@
|
|||||||
|
# Contribute to the Buildx project
|
||||||
|
|
||||||
|
This page contains information about reporting issues as well as some tips and
|
||||||
|
guidelines useful to experienced open source contributors.
|
||||||
|
|
||||||
|
## Reporting security issues
|
||||||
|
|
||||||
|
The project maintainers take security seriously. If you discover a security
|
||||||
|
issue, please bring it to their attention right away!
|
||||||
|
|
||||||
|
**Please _DO NOT_ file a public issue**, instead send your report privately to
|
||||||
|
[security@docker.com](mailto:security@docker.com).
|
||||||
|
|
||||||
|
Security reports are greatly appreciated and we will publicly thank you for it.
|
||||||
|
We also like to send gifts—if you're into schwag, make sure to let
|
||||||
|
us know. We currently do not offer a paid security bounty program, but are not
|
||||||
|
ruling it out in the future.
|
||||||
|
|
||||||
|
|
||||||
|
## Reporting other issues
|
||||||
|
|
||||||
|
A great way to contribute to the project is to send a detailed report when you
|
||||||
|
encounter an issue. We always appreciate a well-written, thorough bug report,
|
||||||
|
and will thank you for it!
|
||||||
|
|
||||||
|
Check that [our issue database](https://github.com/docker/buildx/issues)
|
||||||
|
doesn't already include that problem or suggestion before submitting an issue.
|
||||||
|
If you find a match, you can use the "subscribe" button to get notified on
|
||||||
|
updates. Do *not* leave random "+1" or "I have this too" comments, as they
|
||||||
|
only clutter the discussion, and don't help resolving it. However, if you
|
||||||
|
have ways to reproduce the issue or have additional information that may help
|
||||||
|
resolving the issue, please leave a comment.
|
||||||
|
|
||||||
|
Include the steps required to reproduce the problem if possible and applicable.
|
||||||
|
This information will help us review and fix your issue faster. When sending
|
||||||
|
lengthy log-files, consider posting them as an attachment, instead of posting
|
||||||
|
inline.
|
||||||
|
|
||||||
|
**Do not forget to remove sensitive data from your logfiles before submitting**
|
||||||
|
(you can replace those parts with "REDACTED").
|
||||||
|
|
||||||
|
### Pull requests are always welcome
|
||||||
|
|
||||||
|
Not sure if that typo is worth a pull request? Found a bug and know how to fix
|
||||||
|
it? Do it! We will appreciate it.
|
||||||
|
|
||||||
|
If your pull request is not accepted on the first try, don't be discouraged! If
|
||||||
|
there's a problem with the implementation, hopefully you received feedback on
|
||||||
|
what to improve.
|
||||||
|
|
||||||
|
We're trying very hard to keep Buildx lean and focused. We don't want it to
|
||||||
|
do everything for everybody. This means that we might decide against
|
||||||
|
incorporating a new feature. However, there might be a way to implement that
|
||||||
|
feature *on top of* Buildx.
|
||||||
|
|
||||||
|
### Design and cleanup proposals
|
||||||
|
|
||||||
|
You can propose new designs for existing features. You can also design
|
||||||
|
entirely new features. We really appreciate contributors who want to refactor or
|
||||||
|
otherwise cleanup our project.
|
||||||
|
|
||||||
|
### Sign your work
|
||||||
|
|
||||||
|
The sign-off is a simple line at the end of the explanation for the patch. Your
|
||||||
|
signature certifies that you wrote the patch or otherwise have the right to pass
|
||||||
|
it on as an open-source patch. The rules are pretty simple: if you can certify
|
||||||
|
the below (from [developercertificate.org](http://developercertificate.org/)):
|
||||||
|
|
||||||
|
```
|
||||||
|
Developer Certificate of Origin
|
||||||
|
Version 1.1
|
||||||
|
|
||||||
|
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
|
||||||
|
1 Letterman Drive
|
||||||
|
Suite D4700
|
||||||
|
San Francisco, CA, 94129
|
||||||
|
|
||||||
|
Everyone is permitted to copy and distribute verbatim copies of this
|
||||||
|
license document, but changing it is not allowed.
|
||||||
|
|
||||||
|
Developer's Certificate of Origin 1.1
|
||||||
|
|
||||||
|
By making a contribution to this project, I certify that:
|
||||||
|
|
||||||
|
(a) The contribution was created in whole or in part by me and I
|
||||||
|
have the right to submit it under the open source license
|
||||||
|
indicated in the file; or
|
||||||
|
|
||||||
|
(b) The contribution is based upon previous work that, to the best
|
||||||
|
of my knowledge, is covered under an appropriate open source
|
||||||
|
license and I have the right under that license to submit that
|
||||||
|
work with modifications, whether created in whole or in part
|
||||||
|
by me, under the same open source license (unless I am
|
||||||
|
permitted to submit under a different license), as indicated
|
||||||
|
in the file; or
|
||||||
|
|
||||||
|
(c) The contribution was provided directly to me by some other
|
||||||
|
person who certified (a), (b) or (c) and I have not modified
|
||||||
|
it.
|
||||||
|
|
||||||
|
(d) I understand and agree that this project and the contribution
|
||||||
|
are public and that a record of the contribution (including all
|
||||||
|
personal information I submit with it, including my sign-off) is
|
||||||
|
maintained indefinitely and may be redistributed consistent with
|
||||||
|
this project or the open source license(s) involved.
|
||||||
|
```
|
||||||
|
|
||||||
|
Then you just add a line to every git commit message:
|
||||||
|
|
||||||
|
Signed-off-by: Joe Smith <joe.smith@email.com>
|
||||||
|
|
||||||
|
**Use your real name** (sorry, no pseudonyms or anonymous contributions.)
|
||||||
|
|
||||||
|
If you set your `user.name` and `user.email` git configs, you can sign your
|
||||||
|
commit automatically with `git commit -s`.
|
||||||
|
|
||||||
|
### Run the unit- and integration-tests
|
||||||
|
|
||||||
|
To enter a demo container environment and experiment, you may run:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ make shell
|
||||||
|
```
|
||||||
|
|
||||||
|
To validate PRs before submitting them you should run:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ make validate-all
|
||||||
|
```
|
||||||
|
|
||||||
|
To generate new vendored files with go modules run:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ make vendor
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
### Conventions
|
||||||
|
|
||||||
|
- Fork the repository and make changes on your fork in a feature branch
|
||||||
|
- Submit tests for your changes. See [run the unit- and integration-tests](#run-the-unit--and-integration-tests)
|
||||||
|
for details.
|
||||||
|
- [Sign your work](#sign-your-work)
|
||||||
|
|
||||||
|
Write clean code. Universally formatted code promotes ease of writing, reading,
|
||||||
|
and maintenance. Always run `gofmt -s -w file.go` on each changed file before
|
||||||
|
committing your changes. Most editors have plug-ins that do this automatically.
|
||||||
|
|
||||||
|
Pull request descriptions should be as clear as possible and include a
|
||||||
|
reference to all the issues that they address. Be sure that the [commit
|
||||||
|
messages](#commit-messages) also contain the relevant information.
|
||||||
|
|
||||||
|
### Successful Changes
|
||||||
|
|
||||||
|
Before contributing large or high impact changes, make the effort to coordinate
|
||||||
|
with the maintainers of the project before submitting a pull request. This
|
||||||
|
prevents you from doing extra work that may or may not be merged.
|
||||||
|
|
||||||
|
Large PRs that are just submitted without any prior communication are unlikely
|
||||||
|
to be successful.
|
||||||
|
|
||||||
|
While pull requests are the methodology for submitting changes to code, changes
|
||||||
|
are much more likely to be accepted if they are accompanied by additional
|
||||||
|
engineering work. While we don't define this explicitly, most of these goals
|
||||||
|
are accomplished through communication of the design goals and subsequent
|
||||||
|
solutions. Often times, it helps to first state the problem before presenting
|
||||||
|
solutions.
|
||||||
|
|
||||||
|
Typically, the best methods of accomplishing this are to submit an issue,
|
||||||
|
stating the problem. This issue can include a problem statement and a
|
||||||
|
checklist with requirements. If solutions are proposed, alternatives should be
|
||||||
|
listed and eliminated. Even if the criteria for elimination of a solution is
|
||||||
|
frivolous, say so.
|
||||||
|
|
||||||
|
Larger changes typically work best with design documents. These are focused on
|
||||||
|
providing context to the design at the time the feature was conceived and can
|
||||||
|
inform future documentation contributions.
|
||||||
|
|
||||||
|
### Commit Messages
|
||||||
|
|
||||||
|
Commit messages must start with a capitalized and short summary (max. 50 chars)
|
||||||
|
written in the imperative, followed by an optional, more detailed explanatory
|
||||||
|
text which is separated from the summary by an empty line.
|
||||||
|
|
||||||
|
Commit messages should follow best practices, including explaining the context
|
||||||
|
of the problem and how it was solved, including in caveats or follow up changes
|
||||||
|
required. They should tell the story of the change and provide readers
|
||||||
|
understanding of what led to it.
|
||||||
|
|
||||||
|
If you're lost about what this even means, please see [How to Write a Git
|
||||||
|
Commit Message](http://chris.beams.io/posts/git-commit/) for a start.
|
||||||
|
|
||||||
|
In practice, the best approach to maintaining a nice commit message is to
|
||||||
|
leverage a `git add -p` and `git commit --amend` to formulate a solid
|
||||||
|
changeset. This allows one to piece together a change, as information becomes
|
||||||
|
available.
|
||||||
|
|
||||||
|
If you squash a series of commits, don't just submit that. Re-write the commit
|
||||||
|
message, as if the series of commits was a single stroke of brilliance.
|
||||||
|
|
||||||
|
That said, there is no requirement to have a single commit for a PR, as long as
|
||||||
|
each commit tells the story. For example, if there is a feature that requires a
|
||||||
|
package, it might make sense to have the package in a separate commit then have
|
||||||
|
a subsequent commit that uses it.
|
||||||
|
|
||||||
|
Remember, you're telling part of the story with the commit message. Don't make
|
||||||
|
your chapter weird.
|
||||||
|
|
||||||
|
### Review
|
||||||
|
|
||||||
|
Code review comments may be added to your pull request. Discuss, then make the
|
||||||
|
suggested modifications and push additional commits to your feature branch. Post
|
||||||
|
a comment after pushing. New commits show up in the pull request automatically,
|
||||||
|
but the reviewers are notified only when you comment.
|
||||||
|
|
||||||
|
Pull requests must be cleanly rebased on top of master without multiple branches
|
||||||
|
mixed into the PR.
|
||||||
|
|
||||||
|
> **Git tip**: If your PR no longer merges cleanly, use `rebase master` in your
|
||||||
|
> feature branch to update your pull request rather than `merge master`.
|
||||||
|
|
||||||
|
Before you make a pull request, squash your commits into logical units of work
|
||||||
|
using `git rebase -i` and `git push -f`. A logical unit of work is a consistent
|
||||||
|
set of patches that should be reviewed together: for example, upgrading the
|
||||||
|
version of a vendored dependency and taking advantage of its now available new
|
||||||
|
feature constitute two separate units of work. Implementing a new function and
|
||||||
|
calling it in another file constitute a single logical unit of work. The very
|
||||||
|
high majority of submissions should have a single commit, so if in doubt: squash
|
||||||
|
down to one.
|
||||||
|
|
||||||
|
- After every commit, [make sure the test suite passes](#run-the-unit--and-integration-tests).
|
||||||
|
Include documentation changes in the same pull request so that a revert would
|
||||||
|
remove all traces of the feature or fix.
|
||||||
|
- Include an issue reference like `closes #XXXX` or `fixes #XXXX` in the PR
|
||||||
|
description that close an issue. Including references automatically closes
|
||||||
|
the issue on a merge.
|
||||||
|
- Do not add yourself to the `AUTHORS` file, as it is regenerated regularly
|
||||||
|
from the Git history.
|
||||||
|
- See the [Coding Style](#coding-style) for further guidelines.
|
||||||
|
|
||||||
|
|
||||||
|
### Merge approval
|
||||||
|
|
||||||
|
Project maintainers use LGTM (Looks Good To Me) in comments on the code review to
|
||||||
|
indicate acceptance, or use the Github review approval feature.
|
||||||
|
|
||||||
|
|
||||||
|
## Coding Style
|
||||||
|
|
||||||
|
Unless explicitly stated, we follow all coding guidelines from the Go
|
||||||
|
community. While some of these standards may seem arbitrary, they somehow seem
|
||||||
|
to result in a solid, consistent codebase.
|
||||||
|
|
||||||
|
It is possible that the code base does not currently comply with these
|
||||||
|
guidelines. We are not looking for a massive PR that fixes this, since that
|
||||||
|
goes against the spirit of the guidelines. All new contributions should make a
|
||||||
|
best effort to clean up and make the code base better than they left it.
|
||||||
|
Obviously, apply your best judgement. Remember, the goal here is to make the
|
||||||
|
code base easier for humans to navigate and understand. Always keep that in
|
||||||
|
mind when nudging others to comply.
|
||||||
|
|
||||||
|
The rules:
|
||||||
|
|
||||||
|
1. All code should be formatted with `gofmt -s`.
|
||||||
|
2. All code should pass the default levels of
|
||||||
|
[`golint`](https://github.com/golang/lint).
|
||||||
|
3. All code should follow the guidelines covered in [Effective
|
||||||
|
Go](http://golang.org/doc/effective_go.html) and [Go Code Review
|
||||||
|
Comments](https://github.com/golang/go/wiki/CodeReviewComments).
|
||||||
|
4. Comment the code. Tell us the why, the history and the context.
|
||||||
|
5. Document _all_ declarations and methods, even private ones. Declare
|
||||||
|
expectations, caveats and anything else that may be important. If a type
|
||||||
|
gets exported, having the comments already there will ensure it's ready.
|
||||||
|
6. Variable name length should be proportional to its context and no longer.
|
||||||
|
`noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo`.
|
||||||
|
In practice, short methods will have short variable names and globals will
|
||||||
|
have longer names.
|
||||||
|
7. No underscores in package names. If you need a compound name, step back,
|
||||||
|
and re-examine why you need a compound name. If you still think you need a
|
||||||
|
compound name, lose the underscore.
|
||||||
|
8. No utils or helpers packages. If a function is not general enough to
|
||||||
|
warrant its own package, it has not been written generally enough to be a
|
||||||
|
part of a util package. Just leave it unexported and well-documented.
|
||||||
|
9. All tests should run with `go test` and outside tooling should not be
|
||||||
|
required. No, we don't need another unit testing framework. Assertion
|
||||||
|
packages are acceptable if they provide _real_ incremental value.
|
||||||
|
10. Even though we call these "rules" above, they are actually just
|
||||||
|
guidelines. Since you've read all the rules, you now know that.
|
||||||
|
|
||||||
|
If you are having trouble getting into the mood of idiomatic Go, we recommend
|
||||||
|
reading through [Effective Go](https://golang.org/doc/effective_go.html). The
|
||||||
|
[Go Blog](https://blog.golang.org) is also a great resource.
|
||||||
@ -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 <tibor@docker.com>
|
||||||
|
Tibor Vass <tibor@docker.com> <tiborvass@users.noreply.github.com>
|
||||||
|
Tõnis Tiigi <tonistiigi@gmail.com>
|
||||||
@ -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 <bindu@microsoft.com>
|
||||||
|
Brian Goff <cpuguy83@gmail.com>
|
||||||
|
Tibor Vass <tibor@docker.com>
|
||||||
|
Tõnis Tiigi <tonistiigi@gmail.com>
|
||||||
@ -0,0 +1,202 @@
|
|||||||
|
|
||||||
|
Apache License
|
||||||
|
Version 2.0, January 2004
|
||||||
|
http://www.apache.org/licenses/
|
||||||
|
|
||||||
|
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
||||||
|
|
||||||
|
1. Definitions.
|
||||||
|
|
||||||
|
"License" shall mean the terms and conditions for use, reproduction,
|
||||||
|
and distribution as defined by Sections 1 through 9 of this document.
|
||||||
|
|
||||||
|
"Licensor" shall mean the copyright owner or entity authorized by
|
||||||
|
the copyright owner that is granting the License.
|
||||||
|
|
||||||
|
"Legal Entity" shall mean the union of the acting entity and all
|
||||||
|
other entities that control, are controlled by, or are under common
|
||||||
|
control with that entity. For the purposes of this definition,
|
||||||
|
"control" means (i) the power, direct or indirect, to cause the
|
||||||
|
direction or management of such entity, whether by contract or
|
||||||
|
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
||||||
|
outstanding shares, or (iii) beneficial ownership of such entity.
|
||||||
|
|
||||||
|
"You" (or "Your") shall mean an individual or Legal Entity
|
||||||
|
exercising permissions granted by this License.
|
||||||
|
|
||||||
|
"Source" form shall mean the preferred form for making modifications,
|
||||||
|
including but not limited to software source code, documentation
|
||||||
|
source, and configuration files.
|
||||||
|
|
||||||
|
"Object" form shall mean any form resulting from mechanical
|
||||||
|
transformation or translation of a Source form, including but
|
||||||
|
not limited to compiled object code, generated documentation,
|
||||||
|
and conversions to other media types.
|
||||||
|
|
||||||
|
"Work" shall mean the work of authorship, whether in Source or
|
||||||
|
Object form, made available under the License, as indicated by a
|
||||||
|
copyright notice that is included in or attached to the work
|
||||||
|
(an example is provided in the Appendix below).
|
||||||
|
|
||||||
|
"Derivative Works" shall mean any work, whether in Source or Object
|
||||||
|
form, that is based on (or derived from) the Work and for which the
|
||||||
|
editorial revisions, annotations, elaborations, or other modifications
|
||||||
|
represent, as a whole, an original work of authorship. For the purposes
|
||||||
|
of this License, Derivative Works shall not include works that remain
|
||||||
|
separable from, or merely link (or bind by name) to the interfaces of,
|
||||||
|
the Work and Derivative Works thereof.
|
||||||
|
|
||||||
|
"Contribution" shall mean any work of authorship, including
|
||||||
|
the original version of the Work and any modifications or additions
|
||||||
|
to that Work or Derivative Works thereof, that is intentionally
|
||||||
|
submitted to Licensor for inclusion in the Work by the copyright owner
|
||||||
|
or by an individual or Legal Entity authorized to submit on behalf of
|
||||||
|
the copyright owner. For the purposes of this definition, "submitted"
|
||||||
|
means any form of electronic, verbal, or written communication sent
|
||||||
|
to the Licensor or its representatives, including but not limited to
|
||||||
|
communication on electronic mailing lists, source code control systems,
|
||||||
|
and issue tracking systems that are managed by, or on behalf of, the
|
||||||
|
Licensor for the purpose of discussing and improving the Work, but
|
||||||
|
excluding communication that is conspicuously marked or otherwise
|
||||||
|
designated in writing by the copyright owner as "Not a Contribution."
|
||||||
|
|
||||||
|
"Contributor" shall mean Licensor and any individual or Legal Entity
|
||||||
|
on behalf of whom a Contribution has been received by Licensor and
|
||||||
|
subsequently incorporated within the Work.
|
||||||
|
|
||||||
|
2. Grant of Copyright License. Subject to the terms and conditions of
|
||||||
|
this License, each Contributor hereby grants to You a perpetual,
|
||||||
|
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||||
|
copyright license to reproduce, prepare Derivative Works of,
|
||||||
|
publicly display, publicly perform, sublicense, and distribute the
|
||||||
|
Work and such Derivative Works in Source or Object form.
|
||||||
|
|
||||||
|
3. Grant of Patent License. Subject to the terms and conditions of
|
||||||
|
this License, each Contributor hereby grants to You a perpetual,
|
||||||
|
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||||
|
(except as stated in this section) patent license to make, have made,
|
||||||
|
use, offer to sell, sell, import, and otherwise transfer the Work,
|
||||||
|
where such license applies only to those patent claims licensable
|
||||||
|
by such Contributor that are necessarily infringed by their
|
||||||
|
Contribution(s) alone or by combination of their Contribution(s)
|
||||||
|
with the Work to which such Contribution(s) was submitted. If You
|
||||||
|
institute patent litigation against any entity (including a
|
||||||
|
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
||||||
|
or a Contribution incorporated within the Work constitutes direct
|
||||||
|
or contributory patent infringement, then any patent licenses
|
||||||
|
granted to You under this License for that Work shall terminate
|
||||||
|
as of the date such litigation is filed.
|
||||||
|
|
||||||
|
4. Redistribution. You may reproduce and distribute copies of the
|
||||||
|
Work or Derivative Works thereof in any medium, with or without
|
||||||
|
modifications, and in Source or Object form, provided that You
|
||||||
|
meet the following conditions:
|
||||||
|
|
||||||
|
(a) You must give any other recipients of the Work or
|
||||||
|
Derivative Works a copy of this License; and
|
||||||
|
|
||||||
|
(b) You must cause any modified files to carry prominent notices
|
||||||
|
stating that You changed the files; and
|
||||||
|
|
||||||
|
(c) You must retain, in the Source form of any Derivative Works
|
||||||
|
that You distribute, all copyright, patent, trademark, and
|
||||||
|
attribution notices from the Source form of the Work,
|
||||||
|
excluding those notices that do not pertain to any part of
|
||||||
|
the Derivative Works; and
|
||||||
|
|
||||||
|
(d) If the Work includes a "NOTICE" text file as part of its
|
||||||
|
distribution, then any Derivative Works that You distribute must
|
||||||
|
include a readable copy of the attribution notices contained
|
||||||
|
within such NOTICE file, excluding those notices that do not
|
||||||
|
pertain to any part of the Derivative Works, in at least one
|
||||||
|
of the following places: within a NOTICE text file distributed
|
||||||
|
as part of the Derivative Works; within the Source form or
|
||||||
|
documentation, if provided along with the Derivative Works; or,
|
||||||
|
within a display generated by the Derivative Works, if and
|
||||||
|
wherever such third-party notices normally appear. The contents
|
||||||
|
of the NOTICE file are for informational purposes only and
|
||||||
|
do not modify the License. You may add Your own attribution
|
||||||
|
notices within Derivative Works that You distribute, alongside
|
||||||
|
or as an addendum to the NOTICE text from the Work, provided
|
||||||
|
that such additional attribution notices cannot be construed
|
||||||
|
as modifying the License.
|
||||||
|
|
||||||
|
You may add Your own copyright statement to Your modifications and
|
||||||
|
may provide additional or different license terms and conditions
|
||||||
|
for use, reproduction, or distribution of Your modifications, or
|
||||||
|
for any such Derivative Works as a whole, provided Your use,
|
||||||
|
reproduction, and distribution of the Work otherwise complies with
|
||||||
|
the conditions stated in this License.
|
||||||
|
|
||||||
|
5. Submission of Contributions. Unless You explicitly state otherwise,
|
||||||
|
any Contribution intentionally submitted for inclusion in the Work
|
||||||
|
by You to the Licensor shall be under the terms and conditions of
|
||||||
|
this License, without any additional terms or conditions.
|
||||||
|
Notwithstanding the above, nothing herein shall supersede or modify
|
||||||
|
the terms of any separate license agreement you may have executed
|
||||||
|
with Licensor regarding such Contributions.
|
||||||
|
|
||||||
|
6. Trademarks. This License does not grant permission to use the trade
|
||||||
|
names, trademarks, service marks, or product names of the Licensor,
|
||||||
|
except as required for reasonable and customary use in describing the
|
||||||
|
origin of the Work and reproducing the content of the NOTICE file.
|
||||||
|
|
||||||
|
7. Disclaimer of Warranty. Unless required by applicable law or
|
||||||
|
agreed to in writing, Licensor provides the Work (and each
|
||||||
|
Contributor provides its Contributions) on an "AS IS" BASIS,
|
||||||
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
||||||
|
implied, including, without limitation, any warranties or conditions
|
||||||
|
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
||||||
|
PARTICULAR PURPOSE. You are solely responsible for determining the
|
||||||
|
appropriateness of using or redistributing the Work and assume any
|
||||||
|
risks associated with Your exercise of permissions under this License.
|
||||||
|
|
||||||
|
8. Limitation of Liability. In no event and under no legal theory,
|
||||||
|
whether in tort (including negligence), contract, or otherwise,
|
||||||
|
unless required by applicable law (such as deliberate and grossly
|
||||||
|
negligent acts) or agreed to in writing, shall any Contributor be
|
||||||
|
liable to You for damages, including any direct, indirect, special,
|
||||||
|
incidental, or consequential damages of any character arising as a
|
||||||
|
result of this License or out of the use or inability to use the
|
||||||
|
Work (including but not limited to damages for loss of goodwill,
|
||||||
|
work stoppage, computer failure or malfunction, or any and all
|
||||||
|
other commercial damages or losses), even if such Contributor
|
||||||
|
has been advised of the possibility of such damages.
|
||||||
|
|
||||||
|
9. Accepting Warranty or Additional Liability. While redistributing
|
||||||
|
the Work or Derivative Works thereof, You may choose to offer,
|
||||||
|
and charge a fee for, acceptance of support, warranty, indemnity,
|
||||||
|
or other liability obligations and/or rights consistent with this
|
||||||
|
License. However, in accepting such obligations, You may act only
|
||||||
|
on Your own behalf and on Your sole responsibility, not on behalf
|
||||||
|
of any other Contributor, and only if You agree to indemnify,
|
||||||
|
defend, and hold each Contributor harmless for any liability
|
||||||
|
incurred by, or claims asserted against, such Contributor by reason
|
||||||
|
of your accepting any such warranty or additional liability.
|
||||||
|
|
||||||
|
END OF TERMS AND CONDITIONS
|
||||||
|
|
||||||
|
APPENDIX: How to apply the Apache License to your work.
|
||||||
|
|
||||||
|
To apply the Apache License to your work, attach the following
|
||||||
|
boilerplate notice, with the fields enclosed by brackets "[]"
|
||||||
|
replaced with your own identifying information. (Don't include
|
||||||
|
the brackets!) The text should be enclosed in the appropriate
|
||||||
|
comment syntax for the file format. We also recommend that a
|
||||||
|
file or class name and description of purpose be included on the
|
||||||
|
same "printed page" as the copyright notice for easier
|
||||||
|
identification within third-party archives.
|
||||||
|
|
||||||
|
Copyright [yyyy] [name of copyright owner]
|
||||||
|
|
||||||
|
Licensed under the Apache License, Version 2.0 (the "License");
|
||||||
|
you may not use this file except in compliance with the License.
|
||||||
|
You may obtain a copy of the License at
|
||||||
|
|
||||||
|
http://www.apache.org/licenses/LICENSE-2.0
|
||||||
|
|
||||||
|
Unless required by applicable law or agreed to in writing, software
|
||||||
|
distributed under the License is distributed on an "AS IS" BASIS,
|
||||||
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||||
|
See the License for the specific language governing permissions and
|
||||||
|
limitations under the License.
|
||||||
@ -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 = "github@gone.nl"
|
||||||
|
GitHub = "thaJeztah"
|
||||||
|
|
||||||
|
[people.tiborvass]
|
||||||
|
Name = "Tibor Vass"
|
||||||
|
Email = "tibor@docker.com"
|
||||||
|
GitHub = "tiborvass"
|
||||||
|
|
||||||
|
[people.tonistiigi]
|
||||||
|
Name = "Tõnis Tiigi"
|
||||||
|
Email = "tonis@docker.com"
|
||||||
|
GitHub = "tonistiigi"
|
||||||
@ -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
|
||||||
Loading…
Reference in New Issue