d8dfun/virtual-kubelet
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Ria Bhatia
2017-12-04 13:32:57 -06:00
committed by Erik St. Martin
commit 0075e5b0f3
9056 changed files with 2523100 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
vendor/github.com/hyperhq/hypercli/project/ARM.md generated vendored Normal file
View File

@@ -0,0 +1,30 @@
# ARM support
The ARM support should be considered experimental. It will be extended step by step in the coming weeks.
Building a Docker Development Image works in the same fashion as for Intel platform (x86-64).
Currently we have initial support for 32bit ARMv7 devices.
To work with the Docker Development Image you have to clone the Docker/Docker repo on a supported device.
It needs to have a Docker Engine installed to build the Docker Development Image.
From the root of the Docker/Docker repo one can use make to execute the following make targets:
- make validate
- make binary
- make build
- make deb
- make bundles
- make default
- make shell
- make test-unit
- make test-integration-cli
- make
The Makefile does include logic to determine on which OS and architecture the Docker Development Image is built.
Based on OS and architecture it chooses the correct Dockerfile.
For the ARM 32bit architecture it uses `Dockerfile.armhf`.
So for example in order to build a Docker binary one has to
1. clone the Docker/Docker repository on an ARM device `git clone git@github.com:docker/docker.git`
2. change into the checked out repository with `cd docker`
3. execute `make binary` to create a Docker Engine binary for ARM

35
vendor/github.com/hyperhq/hypercli/project/BRANCHES-AND-TAGS.md generated vendored Normal file
View File

@@ -0,0 +1,35 @@
Branches and tags
=================
Note: details of the release process for the Engine are documented in the
[RELEASE-CHECKLIST](https://github.com/docker/docker/blob/master/project/RELEASE-CHECKLIST.md).
# Branches
The docker/docker repository should normally have only three living branches at all time, including
the regular `master` branch:
## `docs` branch
The `docs` branch supports documentation updates between product releases. This branch allow us to
decouple documentation releases from product releases.
## `release` branch
The `release` branch contains the last _released_ version of the code for the project.
The `release` branch is only updated at each public release of the project. The mechanism for this
is that the release is materialized by a pull request against the `release` branch which lives for
the duration of the code freeze period. When this pull request is merged, the `release` branch gets
updated, and its new state is tagged accordingly.
# Tags
Any public release of a compiled binary, with the logical exception of nightly builds, should have
a corresponding tag in the repository.
The general format of a tag is `vX.Y.Z[-suffix[N]]`:
- All of `X`, `Y`, `Z` must be specified (example: `v1.0.0`)
- First release candidate for version `1.8.0` should be tagged `v1.8.0-rc1`
- Second alpha release of a product should be tagged `v1.0.0-alpha1`

434
vendor/github.com/hyperhq/hypercli/project/CONTRIBUTORS.md generated vendored Normal file
View File

@@ -0,0 +1,434 @@
# Contributing to Docker
Want to hack on Docker? Awesome! We have a contributor's guide that explains
[setting up a Docker development environment and the contribution
process](https://docs.docker.com/opensource/project/who-written-for/).
![Contributors guide](docs/static_files/contributors.png)
This page contains information about reporting issues as well as some tips and
guidelines useful to experienced open source contributors. Finally, make sure
you read our [community guidelines](#docker-community-guidelines) before you
start participating.
## Topics
* [Reporting Security Issues](#reporting-security-issues)
* [Design and Cleanup Proposals](#design-and-cleanup-proposals)
* [Reporting Issues](#reporting-other-issues)
* [Quick Contribution Tips and Guidelines](#quick-contribution-tips-and-guidelines)
* [Community Guidelines](#docker-community-guidelines)
## Reporting security issues
The Docker 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 Docker 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/docker/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.
When reporting issues, always include:
* The output of `docker version`.
* The output of `docker info`.
Also 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 a gist (https://gist.github.com).
Don't forget to remove sensitive data from your logfiles before posting (you can
replace those parts with "REDACTED").
**Issue Report Template**:
```
Description of problem:
`docker version`:
`docker info`:
`uname -a`:
Environment details (AWS, VirtualBox, physical, etc.):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual Results:
Expected Results:
Additional info:
```
##Quick contribution tips and guidelines
This section gives the experienced contributor some tips and guidelines.
###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. Any significant improvement should be
documented as [a GitHub issue](https://github.com/docker/docker/issues) before
anybody starts working on it.
We are always thrilled to receive pull requests. We do our best to process them
quickly. If your pull request is not accepted on the first try,
don't get discouraged! Our contributor's guide explains [the review process we
use for simple changes](https://docs.docker.com/opensource/workflow/make-a-contribution/).
### Design and cleanup proposals
You can propose new designs for existing Docker features. You can also design
entirely new features. We really appreciate contributors who want to refactor or
otherwise cleanup our project. For information on making these types of
contributions, see [the advanced contribution
section](https://docs.docker.com/opensource/workflow/advanced-contributing/) in
the contributors guide.
We try hard to keep Docker lean and focused. Docker can't 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* Docker.
### Talking to other Docker users and contributors
<table class="tg">
<col width="45%">
<col width="65%">
<tr>
<td>Internet&nbsp;Relay&nbsp;Chat&nbsp;(IRC)</td>
<td>
<p>
IRC a direct line to our most knowledgeable Docker users; we have
both the <code>#docker</code> and <code>#docker-dev</code> group on
<strong>irc.freenode.net</strong>.
IRC is a rich chat protocol but it can overwhelm new users. You can search
<a href="https://botbot.me/freenode/docker/#" target="_blank">our chat archives</a>.
</p>
Read our <a href="https://docs.docker.com/opensource/get-help/#irc-quickstart" target="_blank">IRC quickstart guide</a> for an easy way to get started.
</td>
</tr>
<tr>
<td>Google Groups</td>
<td>
There are two groups.
<a href="https://groups.google.com/forum/#!forum/docker-user" target="_blank">Docker-user</a>
is for people using Docker containers.
The <a href="https://groups.google.com/forum/#!forum/docker-dev" target="_blank">docker-dev</a>
group is for contributors and other people contributing to the Docker
project.
</td>
</tr>
<tr>
<td>Twitter</td>
<td>
You can follow <a href="https://twitter.com/docker/" target="_blank">Docker's Twitter feed</a>
to get updates on our products. You can also tweet us questions or just
share blogs or stories.
</td>
</tr>
<tr>
<td>Stack Overflow</td>
<td>
Stack Overflow has over 17000 Docker questions listed. We regularly
monitor <a href="https://stackoverflow.com/search?tab=newest&q=docker" target="_blank">Docker questions</a>
and so do many other knowledgeable Docker users.
</td>
</tr>
</table>
### Conventions
Fork the repository and make changes on your fork in a feature branch:
- If it's a bug fix branch, name it XXXX-something where XXXX is the number of
the issue.
- If it's a feature branch, create an enhancement issue to announce
your intentions, and name it XXXX-something where XXXX is the number of the
issue.
Submit unit tests for your changes. Go has a great test framework built in; use
it! Take a look at existing tests for inspiration. [Run the full test
suite](https://docs.docker.com/opensource/project/test-and-docs/) on your branch before
submitting a pull request.
Update the documentation when creating or modifying features. Test your
documentation changes for clarity, concision, and correctness, as well as a
clean documentation build. See our contributors guide for [our style
guide](https://docs.docker.com/opensource/doc-style) and instructions on [building
the documentation](https://docs.docker.com/opensource/project/test-and-docs/#build-and-test-the-documentation).
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.
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.
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]
(https://docs.docker.com/opensource/project/test-and-docs/). 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 commits that
close an issue. Including references automatically closes the issue on a merge.
Please do not add yourself to the `AUTHORS` file, as it is regenerated regularly
from the Git history.
Please see the [Coding Style](#coding-style) for further guidelines.
### Merge approval
Docker maintainers use LGTM (Looks Good To Me) in comments on the code review to
indicate acceptance.
A change requires LGTMs from an absolute majority of the maintainers of each
component affected. For example, if a change affects `docs/` and `registry/`, it
needs an absolute majority from the maintainers of `docs/` AND, separately, an
absolute majority of the maintainers of `registry/`.
For more details, see the [MAINTAINERS](MAINTAINERS) page.
### 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.
660 York Street, Suite 102,
San Francisco, CA 94110 USA
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`.
Note that the old-style `Docker-DCO-1.1-Signed-off-by: ...` format is still
accepted, so there is no need to update outstanding pull requests to the new
format right away, but please do adjust your processes for future contributions.
### How can I become a maintainer?
The procedures for adding new maintainers are explained in the
global [MAINTAINERS](https://github.com/docker/opensource/blob/master/MAINTAINERS)
file in the [https://github.com/docker/opensource/](https://github.com/docker/opensource/)
repository.
Don't forget: being a maintainer is a time investment. Make sure you
will have time to make yourself available. You don't have to be a
maintainer to make a difference on the project!
## Docker community guidelines
We want to keep the Docker community awesome, growing and collaborative. We need
your help to keep it that way. To help with this we've come up with some general
guidelines for the community as a whole:
* Be nice: Be courteous, respectful and polite to fellow community members:
no regional, racial, gender, or other abuse will be tolerated. We like
nice people way better than mean ones!
* Encourage diversity and participation: Make everyone in our community feel
welcome, regardless of their background and the extent of their
contributions, and do everything possible to encourage participation in
our community.
* Keep it legal: Basically, don't get us in trouble. Share only content that
you own, do not share private or sensitive information, and don't break
the law.
* Stay on topic: Make sure that you are posting to the correct channel and
avoid off-topic discussions. Remember when you update an issue or respond
to an email you are potentially sending to a large number of people. Please
consider this before you update. Also remember that nobody likes spam.
* Don't send email to the maintainers: There's no need to send email to the
maintainers to ask them to investigate an issue or to take a look at a
pull request. Instead of sending an email, GitHub mentions should be
used to ping maintainers to review a pull request, a proposal or an
issue.
### Guideline violations — 3 strikes method
The point of this section is not to find opportunities to punish people, but we
do need a fair way to deal with people who are making our community suck.
1. First occurrence: We'll give you a friendly, but public reminder that the
behavior is inappropriate according to our guidelines.
2. Second occurrence: We will send you a private message with a warning that
any additional violations will result in removal from the community.
3. Third occurrence: Depending on the violation, we may need to delete or ban
your account.
**Notes:**
* Obvious spammers are banned on first occurrence. If we don't do this, we'll
have spam all over the place.
* Violations are forgiven after 6 months of good behavior, and we won't hold a
grudge.
* People who commit minor infractions will get some education, rather than
hammering them in the 3 strikes process.
* The rules apply equally to everyone in the community, no matter how much
you've contributed.
* Extreme violations of a threatening, abusive, destructive or illegal nature
will be addressed immediately and are not subject to 3 strikes or forgiveness.
* Contact abuse@docker.com to report abuse or appeal violations. In the case of
appeals, we know that mistakes happen, and we'll work with you to come up with a
fair solution if there has been a misunderstanding.
## 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 it's 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 it's 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](http://golang.org/doc/effective_go.html). The
[Go Blog](http://blog.golang.org/) is also a great resource. Drinking the
kool-aid is a lot easier than going thirsty.

17
vendor/github.com/hyperhq/hypercli/project/GOVERNANCE.md generated vendored Normal file
View File

@@ -0,0 +1,17 @@
# Docker Governance Advisory Board Meetings
In the spirit of openness, Docker created a Governance Advisory Board, and committed to make all materials and notes from the meetings of this group public.
All output from the meetings should be considered proposals only, and are subject to the review and approval of the community and the project leadership.
The materials from the first Docker Governance Advisory Board meeting, held on October 28, 2014, are available at
[Google Docs Folder](https://goo.gl/Alfj8r)
These include:
* First Meeting Notes
* DGAB Charter
* Presentation 1: Introductory Presentation, including State of The Project
* Presentation 2: Overall Contribution Structure/Docker Project Core Proposal
* Presentation 3: Long Term Roadmap/Statement of Direction

37
vendor/github.com/hyperhq/hypercli/project/IRC-ADMINISTRATION.md generated vendored Normal file
View File

@@ -0,0 +1,37 @@
# Freenode IRC Administration Guidelines and Tips
This is not meant to be a general "Here's how to IRC" document, so if you're
looking for that, check Google instead. ♥
If you've been charged with helping maintain one of Docker's now many IRC
channels, this might turn out to be useful. If there's information that you
wish you'd known about how a particular channel is organized, you should add
deets here! :)
## `ChanServ`
Most channel maintenance happens by talking to Freenode's `ChanServ` bot. For
example, `/msg ChanServ ACCESS <channel> LIST` will show you a list of everyone
with "access" privileges for a particular channel.
A similar command is used to give someone a particular access level. For
example, to add a new maintainer to the `#docker-maintainers` access list so
that they can contribute to the discussions (after they've been merged
appropriately in a `MAINTAINERS` file, of course), one would use `/msg ChanServ
ACCESS #docker-maintainers ADD <nick> maintainer`.
To setup a new channel with a similar `maintainer` access template, use a
command like `/msg ChanServ TEMPLATE <channel> maintainer +AV` (`+A` for letting
them view the `ACCESS LIST`, `+V` for auto-voice; see `/msg ChanServ HELP FLAGS`
for more details).
## Troubleshooting
The most common cause of not-getting-auto-`+v` woes is people not being
`IDENTIFY`ed with `NickServ` (or their current nickname not being `GROUP`ed with
their main nickname) -- often manifested by `ChanServ` responding to an `ACCESS
ADD` request with something like `xyz is not registered.`.
This is easily fixed by doing `/msg NickServ IDENTIFY OldNick SecretPassword`
followed by `/msg NickServ GROUP` to group the two nicknames together. See
`/msg NickServ HELP GROUP` for more information.

92
vendor/github.com/hyperhq/hypercli/project/ISSUE-TRIAGE.md generated vendored Normal file
View File

@@ -0,0 +1,92 @@
Triaging of issues
------------------
Triage provides an important way to contribute to an open source project. Triage helps ensure issues resolve quickly by:
- Describing the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for an issue to explain how an end user experiences an problem and what actions they took.
- Giving a contributor the information they need before they commit to resolving an issue.
- Lowering the issue count by preventing duplicate issues.
- Streamlining the development process by preventing duplicate discussions.
If you don't have time to code, consider helping with triage. The community will thank you for saving them time by spending some of yours.
### 1. Ensure the issue contains basic information
Before triaging an issue very far, make sure that the issue's author provided the standard issue information. This will help you make an educated recommendation on how this to categorize the issue. Standard information that *must* be included in most issues are things such as:
- the output of `docker version`
- the output of `docker info`
- the output of `uname -a`
- a reproducible case if this is a bug, Dockerfiles FTW
- host distribution and version ( ubuntu 14.04, RHEL, fedora 23 )
- page URL if this is a docs issue or the name of a man page
Depending on the issue, you might not feel all this information is needed. Use your best judgement. If you cannot triage an issue using what its author provided, explain kindly to the author that they must provide the above information to clarify the problem.
If the author provides the standard information but you are still unable to triage the issue, request additional information. Do this kindly and politely because you are asking for more of the author's time.
If the author does not respond requested information within the timespan of a week, close the issue with a kind note stating that the author can request for the issue to be
reopened when the necessary information is provided.
### 2. Classify the Issue
An issue can have multiple of the following labels.
#### Issue kind
| Kind | Description |
|------------------|---------------------------------------------------------------------------------------------------------------------------------|
| kind/bug | Bugs are bugs. The cause may or may not be known at triage time so debugging should be taken account into the time estimate. |
| kind/docs | Writing documentation, man pages, articles, blogs, or other significant word-driven task. |
| kind/enhancement | Enhancement are not bugs or new features but can drastically improve usability or performance of a project component. |
| kind/feature | Functionality or other elements that the project does not currently support. Features are new and shinny. |
| kind/question | Contains a user or contributor question requiring a response. |
#### Functional area
| Area |
|---------------------------|
| area/api |
| area/builder |
| area/cli |
| area/kernel |
| area/runtime |
| area/storage |
| area/storage/aufs |
| area/storage/btrfs |
| area/storage/devicemapper |
| area/storage/overlay |
| area/storage/zfs |
#### Experience level
Experience level is a way for a contributor to find an issue based on their
skill set. Experience types are applied to the issue or pull request using
labels.
| Level | Experience level guideline |
|------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| exp/beginner | New to Docker, and possibly Golang, and is looking to help while learning the basics. |
| exp/intermediate | Comfortable with golang and understands the core concepts of Docker and looking to dive deeper into the project. |
| exp/expert | Proficient with Docker and Golang and has been following, and active in, the community to understand the rationale behind design decisions and where the project is headed. |
As the table states, these labels are meant as guidelines. You might have
written a whole plugin for Docker in a personal project and never contributed to
Docker. With that kind of experience, you could take on an <strong
class="gh-label expert">exp/expert</strong> level task.
### 3. Prioritizing issue
When attached to a specific milestone, an issue can be attributed one of the
following labels to indicate their degree of priority (from more urgent to less
urgent).
| Priority | Description |
|-------------|-----------------------------------------------------------------------------------------------------------------------------------|
| priority/P0 | Urgent: Security, critical bugs, blocking issues. P0 basically means drop everything you are doing until this issue is addressed. |
| priority/P1 | Important: P1 issues are a top priority and a must-have for the next release. |
| priority/P2 | Normal priority: default priority applied. |
| priority/P3 | Best effort: those are nice to have / minor issues. |
And that's it. That should be all the information required for a new or existing contributor to come in an resolve an issue.

74
vendor/github.com/hyperhq/hypercli/project/PACKAGE-REPO-MAINTENANCE.md generated vendored Normal file
View File

@@ -0,0 +1,74 @@
# Apt & Yum Repository Maintenance
## A maintainer's guide to managing Docker's package repos
### How to clean up old experimental debs and rpms
We release debs and rpms for experimental nightly, so these can build up.
To remove old experimental debs and rpms, and _ONLY_ keep the latest, follow the
steps below.
1. Checkout docker master
2. Run clean scripts
```bash
docker build --rm --force-rm -t docker-dev:master .
docker run --rm -it --privileged \
-v /path/to/your/repos/dir:/volumes/repos \
-v $HOME/.gnupg:/root/.gnupg \
-e GPG_PASSPHRASE \
-e DOCKER_RELEASE_DIR=/volumes/repos \
docker-dev:master hack/make.sh clean-apt-repo clean-yum-repo generate-index-listing sign-repos
```
3. Upload the changed repos to `s3` (if you host on s3)
4. Purge the cache, PURGE the cache, PURGE THE CACHE!
### How to get out of a sticky situation
Sh\*t happens. We know. Below are steps to get out of any "hash-sum mismatch" or
"gpg sig error" or the likes error that might happen to the apt repo.
**NOTE:** These are apt repo specific, have had no experimence with anything similar
happening to the yum repo in the past so you can rest easy.
For each step listed below, move on to the next if the previous didn't work.
Otherwise CELEBRATE!
1. Purge the cache.
2. Did you remember to sign the debs after releasing?
Re-sign the repo with your gpg key:
```bash
docker build --rm --force-rm -t docker-dev:master .
docker run --rm -it --privileged \
-v /path/to/your/repos/dir:/volumes/repos \
-v $HOME/.gnupg:/root/.gnupg \
-e GPG_PASSPHRASE \
-e DOCKER_RELEASE_DIR=/volumes/repos \
docker-dev:master hack/make.sh sign-repos
```
Upload the changed repo to `s3` (if that is where you host)
PURGE THE CACHE.
3. Run Jess' magical, save all, only in case of extreme emergencies, "you are
going to have to break this glass to get it" script.
```bash
docker build --rm --force-rm -t docker-dev:master .
docker run --rm -it --privileged \
-v /path/to/your/repos/dir:/volumes/repos \
-v $HOME/.gnupg:/root/.gnupg \
-e GPG_PASSPHRASE \
-e DOCKER_RELEASE_DIR=/volumes/repos \
docker-dev:master hack/make.sh update-apt-repo generate-index-listing sign-repos
```
4. Upload the changed repo to `s3` (if that is where you host)
PURGE THE CACHE.

302
vendor/github.com/hyperhq/hypercli/project/PACKAGERS.md generated vendored Normal file
View File

@@ -0,0 +1,302 @@
# Dear Packager,
If you are looking to make Docker available on your favorite software
distribution, this document is for you. It summarizes the requirements for
building and running the Docker client and the Docker daemon.
## Getting Started
We want to help you package Docker successfully. Before doing any packaging, a
good first step is to introduce yourself on the [docker-dev mailing
list](https://groups.google.com/d/forum/docker-dev), explain what you're trying
to achieve, and tell us how we can help. Don't worry, we don't bite! There might
even be someone already working on packaging for the same distro!
You can also join the IRC channel - #docker and #docker-dev on Freenode are both
active and friendly.
We like to refer to Tianon ("@tianon" on GitHub and "tianon" on IRC) as our
"Packagers Relations", since he's always working to make sure our packagers have
a good, healthy upstream to work with (both in our communication and in our
build scripts). If you're having any kind of trouble, feel free to ping him
directly. He also likes to keep track of what distributions we have packagers
for, so feel free to reach out to him even just to say "Hi!"
## Package Name
If possible, your package should be called "docker". If that name is already
taken, a second choice is "docker-engine". Another possible choice is "docker.io".
## Official Build vs Distro Build
The Docker project maintains its own build and release toolchain. It is pretty
neat and entirely based on Docker (surprise!). This toolchain is the canonical
way to build Docker. We encourage you to give it a try, and if the circumstances
allow you to use it, we recommend that you do.
You might not be able to use the official build toolchain - usually because your
distribution has a toolchain and packaging policy of its own. We get it! Your
house, your rules. The rest of this document should give you the information you
need to package Docker your way, without denaturing it in the process.
## Build Dependencies
To build Docker, you will need the following:
* A recent version of Git and Mercurial
* Go version 1.4 or later
* A clean checkout of the source added to a valid [Go
workspace](https://golang.org/doc/code.html#Workspaces) under the path
*src/github.com/docker/docker* (unless you plan to use `AUTO_GOPATH`,
explained in more detail below)
To build the Docker daemon, you will additionally need:
* An amd64/x86_64 machine running Linux
* SQLite version 3.7.9 or later
* libdevmapper version 1.02.68-cvs (2012-01-26) or later from lvm2 version
2.02.89 or later
* btrfs-progs version 3.16.1 or later (unless using an older version is
absolutely necessary, in which case 3.8 is the minimum)
* libseccomp version 2.2.1 or later (for build tag seccomp)
* yubico-piv-tool version 1.1.0 or later (for experimental)
Be sure to also check out Docker's Dockerfile for the most up-to-date list of
these build-time dependencies.
### Go Dependencies
All Go dependencies are vendored under "./vendor". They are used by the official
build, so the source of truth for the current version of each dependency is
whatever is in "./vendor".
To use the vendored dependencies, simply make sure the path to "./vendor" is
included in `GOPATH` (or use `AUTO_GOPATH`, as explained below).
If you would rather (or must, due to distro policy) package these dependencies
yourself, take a look at "./hack/vendor.sh" for an easy-to-parse list of the
exact version for each.
NOTE: if you're not able to package the exact version (to the exact commit) of a
given dependency, please get in touch so we can remediate! Who knows what
discrepancies can be caused by even the slightest deviation. We promise to do
our best to make everybody happy.
## Stripping Binaries
Please, please, please do not strip any compiled binaries. This is really
important.
In our own testing, stripping the resulting binaries sometimes results in a
binary that appears to work, but more often causes random panics, segfaults, and
other issues. Even if the binary appears to work, please don't strip.
See the following quotes from Dave Cheney, which explain this position better
from the upstream Golang perspective.
### [go issue #5855, comment #3](https://code.google.com/p/go/issues/detail?id=5855#c3)
> Super super important: Do not strip go binaries or archives. It isn't tested,
> often breaks, and doesn't work.
### [launchpad golang issue #1200255, comment #8](https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1200255/comments/8)
> To quote myself: "Please do not strip Go binaries, it is not supported, not
> tested, is often broken, and doesn't do what you want"
>
> To unpack that a bit
>
> * not supported, as in, we don't support it, and recommend against it when
> asked
> * not tested, we don't test stripped binaries as part of the build CI process
> * is often broken, stripping a go binary will produce anywhere from no, to
> subtle, to outright execution failure, see above
### [launchpad golang issue #1200255, comment #13](https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1200255/comments/13)
> To clarify my previous statements.
>
> * I do not disagree with the debian policy, it is there for a good reason
> * Having said that, it stripping Go binaries doesn't work, and nobody is
> looking at making it work, so there is that.
>
> Thanks for patching the build formula.
## Building Docker
Please use our build script ("./hack/make.sh") for all your compilation of
Docker. If there's something you need that it isn't doing, or something it could
be doing to make your life as a packager easier, please get in touch with Tianon
and help us rectify the situation. Chances are good that other packagers have
probably run into the same problems and a fix might already be in the works, but
none of us will know for sure unless you harass Tianon about it. :)
All the commands listed within this section should be run with the Docker source
checkout as the current working directory.
### `AUTO_GOPATH`
If you'd rather not be bothered with the hassles that setting up `GOPATH`
appropriately can be, and prefer to just get a "build that works", you should
add something similar to this to whatever script or process you're using to
build Docker:
```bash
export AUTO_GOPATH=1
```
This will cause the build scripts to set up a reasonable `GOPATH` that
automatically and properly includes both docker/docker from the local
directory, and the local "./vendor" directory as necessary.
### `DOCKER_BUILDTAGS`
If you're building a binary that may need to be used on platforms that include
AppArmor, you will need to set `DOCKER_BUILDTAGS` as follows:
```bash
export DOCKER_BUILDTAGS='apparmor'
```
If you're building a binary that may need to be used on platforms that include
SELinux, you will need to use the `selinux` build tag:
```bash
export DOCKER_BUILDTAGS='selinux'
```
There are build tags for disabling graphdrivers as well. By default, support
for all graphdrivers are built in.
To disable btrfs:
```bash
export DOCKER_BUILDTAGS='exclude_graphdriver_btrfs'
```
To disable devicemapper:
```bash
export DOCKER_BUILDTAGS='exclude_graphdriver_devicemapper'
```
To disable aufs:
```bash
export DOCKER_BUILDTAGS='exclude_graphdriver_aufs'
```
NOTE: if you need to set more than one build tag, space separate them:
```bash
export DOCKER_BUILDTAGS='apparmor selinux exclude_graphdriver_aufs'
```
### Static Daemon
If it is feasible within the constraints of your distribution, you should
seriously consider packaging Docker as a single static binary. A good comparison
is Busybox, which is often packaged statically as a feature to enable mass
portability. Because of the unique way Docker operates, being similarly static
is a "feature".
To build a static Docker daemon binary, run the following command (first
ensuring that all the necessary libraries are available in static form for
linking - see the "Build Dependencies" section above, and the relevant lines
within Docker's own Dockerfile that set up our official build environment):
```bash
./hack/make.sh binary
```
This will create a static binary under
"./bundles/$VERSION/binary/docker-$VERSION", where "$VERSION" is the contents of
the file "./VERSION". This binary is usually installed somewhere like
"/usr/bin/docker".
### Dynamic Daemon / Client-only Binary
If you are only interested in a Docker client binary, set `DOCKER_CLIENTONLY` to a non-empty value using something similar to the following:
```bash
export DOCKER_CLIENTONLY=1
```
If you need to (due to distro policy, distro library availability, or for other
reasons) create a dynamically compiled daemon binary, or if you are only
interested in creating a client binary for Docker, use something similar to the
following:
```bash
./hack/make.sh dynbinary
```
This will create "./bundles/$VERSION/dynbinary/docker-$VERSION", which for
client-only builds is the important file to grab and install as appropriate.
## System Dependencies
### Runtime Dependencies
To function properly, the Docker daemon needs the following software to be
installed and available at runtime:
* iptables version 1.4 or later
* procps (or similar provider of a "ps" executable)
* e2fsprogs version 1.4.12 or later (in use: mkfs.ext4, tune2fs)
* xfsprogs (in use: mkfs.xfs)
* XZ Utils version 4.9 or later
* a [properly
mounted](https://github.com/tianon/cgroupfs-mount/blob/master/cgroupfs-mount)
cgroupfs hierarchy (having a single, all-encompassing "cgroup" mount point
[is](https://github.com/docker/docker/issues/2683)
[not](https://github.com/docker/docker/issues/3485)
[sufficient](https://github.com/docker/docker/issues/4568))
Additionally, the Docker client needs the following software to be installed and
available at runtime:
* Git version 1.7 or later
### Kernel Requirements
The Docker daemon has very specific kernel requirements. Most pre-packaged
kernels already include the necessary options enabled. If you are building your
own kernel, you will either need to discover the options necessary via trial and
error, or check out the [Gentoo
ebuild](https://github.com/tianon/docker-overlay/blob/master/app-emulation/docker/docker-9999.ebuild),
in which a list is maintained (and if there are any issues or discrepancies in
that list, please contact Tianon so they can be rectified).
Note that in client mode, there are no specific kernel requirements, and that
the client will even run on alternative platforms such as Mac OS X / Darwin.
### Optional Dependencies
Some of Docker's features are activated by using optional command-line flags or
by having support for them in the kernel or userspace. A few examples include:
* AUFS graph driver (requires AUFS patches/support enabled in the kernel, and at
least the "auplink" utility from aufs-tools)
* BTRFS graph driver (requires BTRFS support enabled in the kernel)
* ZFS graph driver (requires userspace zfs-utils and a corresponding kernel module)
* Libseccomp to allow running seccomp profiles with containers
## Daemon Init Script
Docker expects to run as a daemon at machine startup. Your package will need to
include a script for your distro's process supervisor of choice. Be sure to
check out the "contrib/init" folder in case a suitable init script already
exists (and if one does not, contact Tianon about whether it might be
appropriate for your distro's init script to live there too!).
In general, Docker should be run as root, similar to the following:
```bash
docker daemon
```
Generally, a `DOCKER_OPTS` variable of some kind is available for adding more
flags (such as changing the graph driver to use BTRFS, switching the location of
"/var/lib/docker", etc).
## Communicate
As a final note, please do feel free to reach out to Tianon at any time for
pretty much anything. He really does love hearing from our packagers and wants
to make sure we're not being a "hostile upstream". As should be a given, we
appreciate the work our packagers do to make sure we have broad distribution!

53
vendor/github.com/hyperhq/hypercli/project/PATCH-RELEASES.md generated vendored Normal file
View File

@@ -0,0 +1,53 @@
# Docker patch (bugfix) release process
Patch releases (the 'Z' in vX.Y.Z) are intended to fix major issues in a
release. Docker open source projects follow these procedures when creating a
patch release;
After each release (both "major" (vX.Y.0) and "patch" releases (vX.Y.Z)), a
patch release milestone (vX.Y.Z + 1) is created.
The creation of a patch release milestone is no obligation to actually
*create* a patch release. The purpose of these milestones is to collect
issues and pull requests that can *justify* a patch release;
- Any maintainer is allowed to add issues and PR's to the milestone, when
doing so, preferably leave a comment on the issue or PR explaining *why*
you think it should be considered for inclusion in a patch release.
- Issues introduced in version vX.Y.0 get added to milestone X.Y.Z+1
- Only *regressions* should be added. Issues *discovered* in version vX.Y.0,
but already present in version vX.Y-1.Z should not be added, unless
critical.
- Patch releases can *only* contain bug-fixes. New features should
*never* be added to a patch release.
The release captain of the "major" (X.Y.0) release, is also responsible for
patch releases. The release captain, together with another maintainer, will
review issues and PRs on the milestone, and assigns `priority/`labels. These
review sessions take place on a weekly basis, more frequent if needed:
- A P0 priority is assigned to critical issues. A maintainer *must* be
assigned to these issues. Maintainers should strive to fix a P0 within a week.
- A P1 priority is assigned to major issues, but not critical. A maintainer
*must* be assigned to these issues.
- P2 and P3 priorities are assigned to other issues. A maintainer can be
assigned.
- Non-critical issues and PR's can be removed from the milestone. Minor
changes, such as typo-fixes or omissions in the documentation can be
considered for inclusion in a patch release.
## Deciding if a patch release should be done
- Only a P0 can justify to proceed with the patch release.
- P1, P2, and P3 issues/PR's should not influence the decision, and
should be moved to the X.Y.Z+1 milestone, or removed from the
milestone.
> **Note**: If the next "major" release is imminent, the release captain
> can decide to cancel a patch release, and include the patches in the
> upcoming major release.
> **Note**: Security releases are also "patch releases", but follow
> a different procedure. Security releases are developed in a private
> repository, released and tested under embargo before they become
> publicly available.

19
vendor/github.com/hyperhq/hypercli/project/PRINCIPLES.md generated vendored Normal file
View File

@@ -0,0 +1,19 @@
# Docker principles
In the design and development of Docker we try to follow these principles:
(Work in progress)
* Don't try to replace every tool. Instead, be an ingredient to improve them.
* Less code is better.
* Fewer components are better. Do you really need to add one more class?
* 50 lines of straightforward, readable code is better than 10 lines of magic that nobody can understand.
* Don't do later what you can do now. "//FIXME: refactor" is not acceptable in new code.
* When hesitating between 2 options, choose the one that is easier to reverse.
* No is temporary, Yes is forever. If you're not sure about a new feature, say no. You can change your mind later.
* Containers must be portable to the greatest possible number of machines. Be suspicious of any change which makes machines less interchangeable.
* The less moving parts in a container, the better.
* Don't merge it unless you document it.
* Don't document it unless you can keep it up-to-date.
* Don't merge it unless you test it!
* Everyone's problem is slightly different. Focus on the part that is the same for everyone, and solve that.

24
vendor/github.com/hyperhq/hypercli/project/README.md generated vendored Normal file
View File

@@ -0,0 +1,24 @@
# Hacking on Docker
The `project/` directory holds information and tools for everyone involved in the process of creating and
distributing Docker, specifically:
## Guides
If you're a *contributor* or aspiring contributor, you should read [CONTRIBUTORS.md](../CONTRIBUTING.md).
If you're a *maintainer* or aspiring maintainer, you should read [MAINTAINERS](../MAINTAINERS).
If you're a *packager* or aspiring packager, you should read [PACKAGERS.md](./PACKAGERS.md).
If you're a maintainer in charge of a *release*, you should read [RELEASE-CHECKLIST.md](./RELEASE-CHECKLIST.md).
## Roadmap
A high-level roadmap is available at [ROADMAP.md](../ROADMAP.md).
## Build tools
[hack/make.sh](../hack/make.sh) is the primary build tool for docker. It is used for compiling the official binary,
running the test suite, and pushing releases.

507
vendor/github.com/hyperhq/hypercli/project/RELEASE-CHECKLIST.md generated vendored Normal file
View File

@@ -0,0 +1,507 @@
# Release Checklist
## A maintainer's guide to releasing Docker
So you're in charge of a Docker release? Cool. Here's what to do.
If your experience deviates from this document, please document the changes
to keep it up-to-date.
It is important to note that this document assumes that the git remote in your
repository that corresponds to "https://github.com/docker/docker" is named
"origin". If yours is not (for example, if you've chosen to name it "upstream"
or something similar instead), be sure to adjust the listed snippets for your
local environment accordingly. If you are not sure what your upstream remote is
named, use a command like `git remote -v` to find out.
If you don't have an upstream remote, you can add one easily using something
like:
```bash
export GITHUBUSER="YOUR_GITHUB_USER"
git remote add origin https://github.com/docker/docker.git
git remote add $GITHUBUSER git@github.com:$GITHUBUSER/docker.git
```
### 1. Pull from master and create a release branch
All releases version numbers will be of the form: vX.Y.Z where X is the major
version number, Y is the minor version number and Z is the patch release version number.
#### Major releases
The release branch name is just vX.Y because it's going to be the basis for all .Z releases.
```bash
export BASE=vX.Y
export VERSION=vX.Y.Z
git fetch origin
git checkout --track origin/master
git checkout -b release/$BASE
```
This new branch is going to be the base for the release. We need to push it to origin so we
can track the cherry-picked changes and the version bump:
```bash
git push origin release/$BASE
```
When you have the major release branch in origin, we need to create the bump fork branch
that we'll push to our fork:
```bash
git checkout -b bump_$VERSION
```
#### Patch releases
If we have the release branch in origin, we can create the forked bump branch from it directly:
```bash
export VERSION=vX.Y.Z
export PATCH=vX.Y.Z+1
git fetch origin
git checkout --track origin/release/$BASE
git checkout -b bump_$PATCH
```
We cherry-pick only the commits we want into the bump branch:
```bash
# get the commits ids we want to cherry-pick
git log
# cherry-pick the commits starting from the oldest one, without including merge commits
git cherry-pick <commit-id>
git cherry-pick <commit-id>
...
```
### 2. Bump the API version on master
We don't want to stop contributions to master just because we are releasing. At
the same time, now that the release branch exists, we don't want API changes to
go to the now frozen API version.
Create a new entry in `docs/reference/api/` by copying the latest and
bumping the version number (in both the file's name and content), and submit
this in a PR against master.
### 3. Update CHANGELOG.md
You can run this command for reference with git 2.0:
```bash
git fetch --tags
LAST_VERSION=$(git tag -l --sort=-version:refname "v*" | grep -E 'v[0-9\.]+$' | head -1)
git log --stat $LAST_VERSION..bump_$VERSION
```
If you don't have git 2.0 but have a sort command that supports `-V`:
```bash
git fetch --tags
LAST_VERSION=$(git tag -l | grep -E 'v[0-9\.]+$' | sort -rV | head -1)
git log --stat $LAST_VERSION..bump_$VERSION
```
If releasing a major version (X or Y increased in vX.Y.Z), simply listing notable user-facing features is sufficient.
```markdown
#### Notable features since <last major version>
* New docker command to do something useful
* Remote API change (deprecating old version)
* Performance improvements in some usecases
* ...
```
For minor releases (only Z increases in vX.Y.Z), provide a list of user-facing changes.
Each change should be listed under a category heading formatted as `#### CATEGORY`.
`CATEGORY` should describe which part of the project is affected.
Valid categories are:
* Builder
* Documentation
* Hack
* Packaging
* Remote API
* Runtime
* Other (please use this category sparingly)
Each change should be formatted as `BULLET DESCRIPTION`, given:
* BULLET: either `-`, `+` or `*`, to indicate a bugfix, new feature or
upgrade, respectively.
* DESCRIPTION: a concise description of the change that is relevant to the
end-user, using the present tense. Changes should be described in terms
of how they affect the user, for example "Add new feature X which allows Y",
"Fix bug which caused X", "Increase performance of Y".
EXAMPLES:
```markdown
## 0.3.6 (1995-12-25)
#### Builder
+ 'docker build -t FOO .' applies the tag FOO to the newly built image
#### Remote API
- Fix a bug in the optional unix socket transport
#### Runtime
* Improve detection of kernel version
```
If you need a list of contributors between the last major release and the
current bump branch, use something like:
```bash
git log --format='%aN <%aE>' v0.7.0...bump_v0.8.0 | sort -uf
```
Obviously, you'll need to adjust version numbers as necessary. If you just need
a count, add a simple `| wc -l`.
### 4. Change the contents of the VERSION file
Before the big thing, you'll want to make successive release candidates and get
people to test. The release candidate number `N` should be part of the version:
```bash
export RC_VERSION=${VERSION}-rcN
echo ${RC_VERSION#v} > VERSION
```
### 5. Test the docs
Make sure that your tree includes documentation for any modified or
new features, syntax or semantic changes.
To test locally:
```bash
make docs
```
To make a shared test at https://beta-docs.docker.io:
(You will need the `awsconfig` file added to the `docs/` dir)
```bash
make AWS_S3_BUCKET=beta-docs.docker.io BUILD_ROOT=yes docs-release
```
### 6. Commit and create a pull request to the "release" branch
```bash
git add VERSION CHANGELOG.md
git commit -m "Bump version to $VERSION"
git push $GITHUBUSER bump_$VERSION
echo "https://github.com/$GITHUBUSER/docker/compare/docker:release/$BASE...$GITHUBUSER:bump_$VERSION?expand=1"
```
That last command will give you the proper link to visit to ensure that you
open the PR against the "release" branch instead of accidentally against
"master" (like so many brave souls before you already have).
### 7. Build release candidate rpms and debs
**NOTE**: It will be a lot faster if you pass a different graphdriver with
`DOCKER_GRAPHDRIVER` than `vfs`.
```bash
docker build -t docker .
docker run \
--rm -t --privileged \
-e DOCKER_GRAPHDRIVER=aufs \
-v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
docker \
hack/make.sh binary build-deb build-rpm
```
### 8. Publish release candidate rpms and debs
With the rpms and debs you built from the last step you can release them on the
same server, or ideally, move them to a dedicated release box via scp into
another docker/docker directory in bundles. This next step assumes you have
a checkout of the docker source code at the same commit you used to build, with
the artifacts from the last step in `bundles`.
**NOTE:** If you put a space before the command your `.bash_history` will not
save it. (for the `GPG_PASSPHRASE`).
```bash
docker build -t docker .
docker run --rm -it --privileged \
-v /volumes/repos:/volumes/repos \
-v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
-v $HOME/.gnupg:/root/.gnupg \
-e DOCKER_RELEASE_DIR=/volumes/repos \
-e GPG_PASSPHRASE \
-e KEEPBUNDLE=1 \
docker \
hack/make.sh release-deb release-rpm sign-repos generate-index-listing
```
### 9. Upload the changed repos to wherever you host
For example, above we bind mounted `/volumes/repos` as the storage for
`DOCKER_RELEASE_DIR`. In this case `/volumes/repos/apt` can be synced with
a specific s3 bucket for the apt repo and `/volumes/repos/yum` can be synced with
a s3 bucket for the yum repo.
### 10. Publish release candidate binaries
To run this you will need access to the release credentials. Get them from the
Core maintainers.
```bash
docker build -t docker .
# static binaries are still pushed to s3
docker run \
-e AWS_S3_BUCKET=test.docker.com \
-e AWS_ACCESS_KEY \
-e AWS_SECRET_KEY \
-i -t --privileged \
docker \
hack/release.sh
```
It will run the test suite, build the binaries and upload to the specified bucket,
so this is a good time to verify that you're running against **test**.docker.com.
### 11. Purge the cache!
After the binaries are uploaded to test.docker.com and the packages are on
apt.dockerproject.org and yum.dockerproject.org, make sure
they get tested in both Ubuntu and Debian for any obvious installation
issues or runtime issues.
If everything looks good, it's time to create a git tag for this candidate:
```bash
git tag -a $RC_VERSION -m $RC_VERSION bump_$VERSION
git push origin $RC_VERSION
```
Announcing on multiple medias is the best way to get some help testing! An easy
way to get some useful links for sharing:
```bash
echo "Ubuntu/Debian: curl -sSL https://test.docker.com/ | sh"
echo "Linux 64bit binary: https://test.docker.com/builds/Linux/x86_64/docker-${VERSION#v}"
echo "Darwin/OSX 64bit client binary: https://test.docker.com/builds/Darwin/x86_64/docker-${VERSION#v}"
echo "Linux 64bit tgz: https://test.docker.com/builds/Linux/x86_64/docker-${VERSION#v}.tgz"
echo "Windows 64bit client binary: https://test.docker.com/builds/Windows/x86_64/docker-${VERSION#v}.exe"
echo "Windows 32bit client binary: https://test.docker.com/builds/Windows/i386/docker-${VERSION#v}.exe"
```
We recommend announcing the release candidate on:
- IRC on #docker, #docker-dev, #docker-maintainers
- In a comment on the pull request to notify subscribed people on GitHub
- The [docker-dev](https://groups.google.com/forum/#!forum/docker-dev) group
- The [docker-maintainers](https://groups.google.com/a/dockerproject.org/forum/#!forum/maintainers) group
- Any social media that can bring some attention to the release candidate
### 12. Iterate on successive release candidates
Spend several days along with the community explicitly investing time and
resources to try and break Docker in every possible way, documenting any
findings pertinent to the release. This time should be spent testing and
finding ways in which the release might have caused various features or upgrade
environments to have issues, not coding. During this time, the release is in
code freeze, and any additional code changes will be pushed out to the next
release.
It should include various levels of breaking Docker, beyond just using Docker
by the book.
Any issues found may still remain issues for this release, but they should be
documented and give appropriate warnings.
During this phase, the `bump_$VERSION` branch will keep evolving as you will
produce new release candidates. The frequency of new candidates is up to the
release manager: use your best judgement taking into account the severity of
reported issues, testers availability, and time to scheduled release date.
Each time you'll want to produce a new release candidate, you will start by
adding commits to the branch, usually by cherry-picking from master:
```bash
git cherry-pick -x -m0 <commit_id>
```
You want your "bump commit" (the one that updates the CHANGELOG and VERSION
files) to remain on top, so you'll have to `git rebase -i` to bring it back up.
Now that your bump commit is back on top, you will need to update the CHANGELOG
file (if appropriate for this particular release candidate), and update the
VERSION file to increment the RC number:
```bash
export RC_VERSION=$VERSION-rcN
echo $RC_VERSION > VERSION
```
You can now amend your last commit and update the bump branch:
```bash
git commit --amend
git push -f $GITHUBUSER bump_$VERSION
```
Repeat step 6 to tag the code, publish new binaries, announce availability, and
get help testing.
### 13. Finalize the bump branch
When you're happy with the quality of a release candidate, you can move on and
create the real thing.
You will first have to amend the "bump commit" to drop the release candidate
suffix in the VERSION file:
```bash
echo $VERSION > VERSION
git add VERSION
git commit --amend
```
You will then repeat step 6 to publish the binaries to test
### 14. Get 2 other maintainers to validate the pull request
### 15. Build final rpms and debs
```bash
docker build -t docker .
docker run \
--rm -t --privileged \
-v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
docker \
hack/make.sh binary build-deb build-rpm
```
### 16. Publish final rpms and debs
With the rpms and debs you built from the last step you can release them on the
same server, or ideally, move them to a dedicated release box via scp into
another docker/docker directory in bundles. This next step assumes you have
a checkout of the docker source code at the same commit you used to build, with
the artifacts from the last step in `bundles`.
**NOTE:** If you put a space before the command your `.bash_history` will not
save it. (for the `GPG_PASSPHRASE`).
```bash
docker build -t docker .
docker run --rm -it --privileged \
-v /volumes/repos:/volumes/repos \
-v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
-v $HOME/.gnupg:/root/.gnupg \
-e DOCKER_RELEASE_DIR=/volumes/repos \
-e GPG_PASSPHRASE \
-e KEEPBUNDLE=1 \
docker \
hack/make.sh release-deb release-rpm sign-repos generate-index-listing
```
### 17. Upload the changed repos to wherever you host
For example, above we bind mounted `/volumes/repos` as the storage for
`DOCKER_RELEASE_DIR`. In this case `/volumes/repos/apt` can be synced with
a specific s3 bucket for the apt repo and `/volumes/repos/yum` can be synced with
a s3 bucket for the yum repo.
### 18. Publish final binaries
Once they're tested and reasonably believed to be working, run against
get.docker.com:
```bash
docker build -t docker .
# static binaries are still pushed to s3
docker run \
-e AWS_S3_BUCKET=get.docker.com \
-e AWS_ACCESS_KEY \
-e AWS_SECRET_KEY \
-i -t --privileged \
docker \
hack/release.sh
```
### 19. Purge the cache!
### 20. Apply tag and create release
It's very important that we don't make the tag until after the official
release is uploaded to get.docker.com!
```bash
git tag -a $VERSION -m $VERSION bump_$VERSION
git push origin $VERSION
```
Once the tag is pushed, go to GitHub and create a [new release](https://github.com/docker/docker/releases/new).
If the tag is for an RC make sure you check `This is a pre-release` at the bottom of the form.
Select the tag that you just pushed as the version and paste the changelog in the description of the release.
You can see examples in this two links:
https://github.com/docker/docker/releases/tag/v1.8.0
https://github.com/docker/docker/releases/tag/v1.8.0-rc3
### 21. Go to github to merge the `bump_$VERSION` branch into release
Don't forget to push that pretty blue button to delete the leftover
branch afterwards!
### 22. Update the docs branch
You will need to point the docs branch to the newly created release tag:
```bash
git checkout origin/docs
git reset --hard origin/$VERSION
git push -f origin docs
```
The docs will appear on https://docs.docker.com/ (though there may be cached
versions, so its worth checking http://docs.docker.com.s3-website-us-east-1.amazonaws.com/).
For more information about documentation releases, see `docs/README.md`.
Note that the new docs will not appear live on the site until the cache (a complex,
distributed CDN system) is flushed. The `make docs-release` command will do this
_if_ the `DISTRIBUTION_ID` is set correctly - this will take at least 15 minutes to run
and you can check its progress with the CDN Cloudfront Chrome addon.
### 23. Create a new pull request to merge your bump commit back into master
```bash
git checkout master
git fetch
git reset --hard origin/master
git cherry-pick $VERSION
git push $GITHUBUSER merge_release_$VERSION
echo "https://github.com/$GITHUBUSER/docker/compare/docker:master...$GITHUBUSER:merge_release_$VERSION?expand=1"
```
Again, get two maintainers to validate, then merge, then push that pretty
blue button to delete your branch.
### 24. Update the VERSION files
Now that version X.Y.Z is out, time to start working on the next! Update the
content of the `VERSION` file to be the next minor (incrementing Y) and add the
`-dev` suffix. For example, after 1.5.0 release, the `VERSION` file gets
updated to `1.6.0-dev` (as in "1.6.0 in the making").
### 25. Rejoice and Evangelize!
Congratulations! You're done.
Go forth and announce the glad tidings of the new release in `#docker`,
`#docker-dev`, on the [dev mailing list](https://groups.google.com/forum/#!forum/docker-dev),
the [announce mailing list](https://groups.google.com/forum/#!forum/docker-announce),
and on Twitter!

78
vendor/github.com/hyperhq/hypercli/project/RELEASE-PROCESS.md generated vendored Normal file
View File

@@ -0,0 +1,78 @@
# Docker Release Process
This document describes how the Docker project is released. The Docker project
release process targets the Engine, Compose, Kitematic, Machine, Swarm,
Distribution, Notary and their underlying dependencies (libnetwork, libkv,
etc...).
Step-by-step technical details of the process are described in
[RELEASE-CHECKLIST.md](https://github.com/docker/docker/blob/master/project/RELEASE-CHECKLIST.md).
## Release cycle
The Docker project follows a **time-based release cycle** and ships every nine
weeks. A release cycle starts the same day the previous release cycle ends.
The first six weeks of the cycle are dedicated to development and review. During
this phase, new features and bugfixes submitted to any of the projects are
**eligible** to be shipped as part of the next release. No changeset submitted
during this period is however guaranteed to be merged for the current release
cycle.
## The freeze period
Six weeks after the beginning of the cycle, the codebase is officially frozen
and the codebase reaches a state close to the final release. A Release Candidate
(RC) gets created at the same time. The freeze period is used to find bugs and
get feedback on the state of the RC before the release.
During this freeze period, while the `master` branch will continue its normal
development cycle, no new features are accepted into the RC. As bugs are fixed
in `master` the release owner will selectively 'cherry-pick' critical ones to
be included into the RC. As the RC changes, new ones are made available for the
community to test and review.
This period lasts for three weeks.
## How to maximize chances of being merged before the freeze date?
First of all, there is never a guarantee that a specific changeset is going to
be merged. However there are different actions to follow to maximize the chances
for a changeset to be merged:
- The team gives priority to review the PRs aligned with the Roadmap (usually
defined by a ROADMAP.md file at the root of the repository).
- The earlier a PR is opened, the more time the maintainers have to review. For
example, if a PR is opened the day before the freeze date, it’s very unlikely
that it will be merged for the release.
- Constant communication with the maintainers (mailing-list, IRC, Github issues,
etc.) allows to get early feedback on the design before getting into the
implementation, which usually reduces the time needed to discuss a changeset.
- If the code is commented, fully tested and by extension follows every single
rules defined by the [CONTRIBUTING guide](
https://github.com/docker/docker/blob/master/CONTRIBUTING.md), this will help
the maintainers by speeding up the review.
## The release
At the end of the freeze (nine weeks after the start of the cycle), all the
projects are released together.
```
Codebase Release
Start of is frozen (end of the
the Cycle (7th week) 9th week)
+---------------------------------------+---------------------+
| | |
| Development phase | Freeze phase |
| | |
+---------------------------------------+---------------------+
6 weeks 3 weeks
<---------------------------------------><-------------------->
```
## Exceptions
If a critical issue is found at the end of the freeze period and more time is
needed to address it, the release will be pushed back. When a release gets
pushed back, the next release cycle gets delayed as well.

194
vendor/github.com/hyperhq/hypercli/project/REVIEWING.md generated vendored Normal file
View File

@@ -0,0 +1,194 @@
Pull request reviewing process
==============================
# Labels
Labels are carefully picked to optimize for:
- Readability: maintainers must immediately know the state of a PR
- Filtering simplicity: different labels represent many different aspects of
the reviewing work, and can even be targeted at different maintainers groups.
A pull request should only be attributed labels documented in this section: other labels that may
exist on the repository should apply to issues.
## DCO labels
* `dco/no`: automatically set by a bot when one of the commits lacks proper signature
## Status labels
* `status/0-triage`
* `status/1-design-review`
* `status/2-code-review`
* `status/3-docs-review`
* `status/4-ready-to-merge`
Special status labels:
* `status/needs-attention`: calls for a collective discussion during a review session
## Specialty group labels
Those labels are used to raise awareness of a particular specialty group, either because we need
help in reviewing the PR, or because of the potential impact of the PR on their work:
* `group/distribution`
* `group/networking`
* `group/security`
* `group/windows`
## Impact labels (apply to merged pull requests)
* `impact/api`
* `impact/changelog`
* `impact/cli`
* `impact/deprecation`
* `impact/distribution`
* `impact/dockerfile`
# Workflow
An opened pull request can be in 1 of 5 distinct states, for each of which there is a corresponding
label that needs to be applied.
## Triage - `status/0-triage`
Maintainers are expected to triage new incoming pull requests by removing the `status/0-triage`
label and adding the correct labels (e.g. `status/1-design-review`) before any other interaction
with the PR. The starting label may potentially skip some steps depending on the kind of pull
request: use your best judgement.
Maintainers should perform an initial, high-level, overview of the pull request before moving it to
the next appropriate stage:
- Has DCO
- Contains sufficient justification (e.g., usecases) for the proposed change
- References the Github issue it fixes (if any) in the commit or the first Github comment
Possible transitions from this state:
* Close: e.g., unresponsive contributor without DCO
* `status/1-design-review`: general case
* `status/2-code-review`: e.g. trivial bugfix
* `status/3-docs-review`: non-proposal documentation-only change
## Design review - `status/1-design-review`
Maintainers are expected to comment on the design of the pull request. Review of documentation is
expected only in the context of design validation, not for stylistic changes.
Ideally, documentation should reflect the expected behavior of the code. No code review should
take place in this step.
There are no strict rules on the way a design is validated: we usually aim for a consensus,
although a single maintainer approval is often sufficient for obviously reasonable changes. In
general, strong disagreement expressed by any of the maintainers should not be taken lightly.
Once design is approved, a maintainer should make sure to remove this label and add the next one.
Possible transitions from this state:
* Close: design rejected
* `status/2-code-review`: general case
* `status/3-docs-review`: proposals with only documentation changes
## Code review - `status/2-code-review`
Maintainers are expected to review the code and ensure that it is good quality and in accordance
with the documentation in the PR.
New testcases are expected to be added. Ideally, those testcases should fail when the new code is
absent, and pass when present. The testcases should strive to test as many variants, code paths, as
possible to ensure maximum coverage.
Changes to code must be reviewed and approved (LGTM'd) by a minimum of two code maintainers. When
the author of a PR is a maintainer, he still needs the approval of two other maintainers.
Once code is approved according to the rules of the subsystem, a maintainer should make sure to
remove this label and add the next one. If documentation is absent but expected, maintainers should
ask for documentation and move to status `status/3-docs-review` for docs maintainer to follow.
Possible transitions from this state:
* Close
* `status/1-design-review`: new design concerns are raised
* `status/3-docs-review`: general case
* `status/4-ready-to-merge`: change not impacting documentation
## Docs review - `status/3-docs-review`
Maintainers are expected to review the documentation in its bigger context, ensuring consistency,
completeness, validity, and breadth of coverage across all existing and new documentation.
They should ask for any editorial change that makes the documentation more consistent and easier to
understand.
Changes and additions to docs must be reviewed and approved (LGTM'd) by a minimum of two docs
sub-project maintainers. If the docs change originates with a docs maintainer, only one additional
LGTM is required (since we assume a docs maintainer approves of their own PR).
Once documentation is approved (see below), a maintainer should make sure to remove this label and
add the next one.
Possible transitions from this state:
* Close
* `status/1-design-review`: new design concerns are raised
* `status/2-code-review`: requires more code changes
* `status/4-ready-to-merge`: general case
## Merge - `status/4-ready-to-merge`
Maintainers are expected to merge this pull request as soon as possible. They can ask for a rebase
or carry the pull request themselves.
Possible transitions from this state:
* Merge: general case
* Close: carry PR
After merging a pull request, the maintainer should consider applying one or multiple impact labels
to ease future classification:
* `impact/api` signifies the patch impacted the remote API
* `impact/changelog` signifies the change is significant enough to make it in the changelog
* `impact/cli` signifies the patch impacted a CLI command
* `impact/dockerfile` signifies the patch impacted the Dockerfile syntax
* `impact/deprecation` signifies the patch participates in deprecating an existing feature
## Close
If a pull request is closed it is expected that sufficient justification will be provided. In
particular, if there are alternative ways of achieving the same net result then those needs to be
spelled out. If the pull request is trying to solve a use case that is not one that we (as a
community) want to support then a justification for why should be provided.
The number of maintainers it takes to decide and close a PR is deliberately left unspecified. We
assume that the group of maintainers is bound by mutual trust and respect, and that opposition from
any single maintainer should be taken into consideration. Similarly, we expect maintainers to
justify their reasoning and to accept debating.
# Escalation process
Despite the previously described reviewing process, some PR might not show any progress for various
reasons:
- No strong opinion for or against the proposed patch
- Debates about the proper way to solve the problem at hand
- Lack of consensus
- ...
All these will eventually lead to stalled PR, where no apparent progress is made across several
weeks, or even months.
Maintainers should use their best judgement and apply the `status/needs-attention` label. It must
be used sparingly, as each PR with such label will be discussed by a group of maintainers during a
review session. The goal of that session is to agree on one of the following outcomes for the PR:
* Close, explaining the rationale for not pursuing further
* Continue, either by pushing the PR further in the workflow, or by deciding to carry the patch
(ideally, a maintainer should be immediately assigned to make sure that the PR keeps continued
attention)
* Escalate to Solomon by formulating a few specific questions on which his answers will allow
maintainers to decide.

63
vendor/github.com/hyperhq/hypercli/project/TOOLS.md generated vendored Normal file
View File

@@ -0,0 +1,63 @@
# Tools
This page describes the tools we use and infrastructure that is in place for
the Docker project.
### CI
The Docker project uses [Jenkins](https://jenkins.dockerproject.org/) as our
continuous integration server. Each Pull Request to Docker is tested by running the
equivalent of `make all`. We chose Jenkins because we can host it ourselves and
we run Docker in Docker to test.
#### Leeroy
Leeroy is a Go application which integrates Jenkins with
GitHub pull requests. Leeroy uses
[GitHub hooks](https://developer.github.com/v3/repos/hooks/)
to listen for pull request notifications and starts jobs on your Jenkins
server. Using the Jenkins
[notification plugin][https://wiki.jenkins-ci.org/display/JENKINS/Notification+Plugin],
Leeroy updates the pull request using GitHub's
[status API](https://developer.github.com/v3/repos/statuses/)
with pending, success, failure, or error statuses.
The leeroy repository is maintained at
[github.com/docker/leeroy](https://github.com/docker/leeroy).
#### GordonTheTurtle IRC Bot
The GordonTheTurtle IRC Bot lives in the
[#docker-maintainers](https://botbot.me/freenode/docker-maintainers/) channel
on Freenode. He is built in Go and is based off the project at
[github.com/fabioxgn/go-bot](https://github.com/fabioxgn/go-bot).
His main command is `!rebuild`, which rebuilds a given Pull Request for a repository.
This command works by integrating with Leroy. He has a few other commands too, such
as `!gif` or `!godoc`, but we are always looking for more fun commands to add.
The gordon-bot repository is maintained at
[github.com/docker/gordon-bot](https://github.com/docker/gordon-bot)
### NSQ
We use [NSQ](https://github.com/bitly/nsq) for various aspects of the project
infrastucture.
#### Hooks
The hooks project,
[github.com/crosbymichael/hooks](https://github.com/crosbymichael/hooks),
is a small Go application that manages web hooks from github, hub.docker.com, or
other third party services.
It can be used for listening to github webhooks & pushing them to a queue,
archiving hooks to rethinkdb for processing, and broadcasting hooks to various
jobs.
#### Docker Master Binaries
One of the things queued from the Hooks are the building of the Master
Binaries. This happens on every push to the master branch of Docker. The
repository for this is maintained at
[github.com/docker/docker-bb](https://github.com/docker/docker-bb).