docker-library
/
docs
mirror of https://github.com/docker-library/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Resolve merge issue

This commit is contained in:
Moghedrin 2014-09-05 13:57:36 -06:00
parent 1561546c56 69d341da4f
commit dc00376c80
19 changed files with 132 additions and 398 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
README-footer.md
View File

@ -1,26 +1,12 @@
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us %%MAILING_LIST%% through a [GitHub issue](https://github.com/docker-library/%%REPO%%/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans %%MAILING_LIST%% through a [GitHub issue](https://github.com/docker-library/%%REPO%%/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
buildpack-deps/README.md
View File

@ -1,27 +1,13 @@
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/buildpack-deps/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/buildpack-deps/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
gcc/README.md
View File

@ -30,28 +30,14 @@ This will add your current directory as a volume to the comtainer, set the worki
docker run --rm -v "$(pwd)":/usr/src/myapp -w /usr/src/myapp gcc make
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/gcc/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/gcc/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
golang/README.md
View File

@ -30,28 +30,14 @@ This will add your current directory as a volume to the comtainer, set the worki
docker run --rm -v "$(pwd)":/usr/src/myapp -w /usr/src/myapp make
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/golang/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/golang/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
hello-world/README.md
View File

@ -21,28 +21,14 @@ $ docker run hello-world
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
hello-world latest 565a9d68a73f 26 hours ago 922 B
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/hello-world/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/hello-world/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
hylang/README.md
View File

@ -4,28 +4,14 @@
# How to use this image
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/hylang/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/hylang/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
java/README.md
View File

@ -31,28 +31,14 @@ This will add your current directory as a volume to the comtainer, set the worki
docker run --rm -v "$(pwd)":/usr/src/myapp -w /usr/src/myapp java make
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/java/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/java/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
mongo/README.md
View File

@ -19,28 +19,14 @@ This image includes `EXPOSE 27017` (the mongo port), so standard container linki
## ... or via `mongo`
docker run -it --link some-mongo:mongo --rm mongo sh -c 'exec mongo "$MONGO_PORT_27017_TCP_ADDR:$MONGO_PORT_27017_TCP_PORT/test"'
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/mongo/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/mongo/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
mysql/README.md
View File

@ -18,28 +18,14 @@ This image includes `EXPOSE 3306` (the mysql port), so standard container linkin
## ... or via `mysql`
docker run -it --link some-mysql:mysql --rm mysql sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -uroot -p"$MYSQL_ENV_MYSQL_ROOT_PASSWORD"'
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/mysql/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/mysql/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
nginx/README.md
View File

@ -46,28 +46,14 @@ Then, build with `docker build -t some-custom-nginx .` and run:
docker run --name some-nginx -d some-custom-nginx
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/nginx/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/nginx/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
node/README.md
View File

@ -23,28 +23,14 @@ Node.js internally uses the Google V8 JavaScript engine to execute code, and a l
# replace this with your main "server" script file
CMD [ "node", "server.js" ]
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/node/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/node/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

26
perl/README.md
View File

@ -23,28 +23,14 @@ For many single file projects, it may not be convenient to write a `Dockerfile`
docker run -it --rm --name my-running-script -v $(pwd):/usr/src/myapp -w /usr/src/myapp perl perl your-daemon-or-script.pl
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/Perl/docker-perl/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/perl/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
## Contributing
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
We recommend discussing your plans through a [GitHub issue](https://github.com/Perl/docker-perl/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

28
postgres/README.md
View File

@ -19,28 +19,14 @@ This image includes `EXPOSE 5432` (the postgres port), so standard container lin
## ... or via `psql`
docker run -it --link some-postgres:postgres --rm postgres sh -c 'exec psql -h "$POSTGRES_PORT_5432_TCP_ADDR" -p "$POSTGRES_PORT_5432_TCP_PORT" -U postgres'
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us on the [mailing list](http://www.postgresql.org/community/lists/subscribe/) or through a [GitHub issue](https://github.com/docker-library/postgres/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans on the [mailing list](http://www.postgresql.org/community/lists/subscribe/) or through a [GitHub issue](https://github.com/docker-library/postgres/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
python/README.md
View File

@ -34,28 +34,14 @@ or (again, if you need to use Python 2):
docker run -it --rm --name my-running-script -v $(pwd):/usr/src/myapp -w /usr/src/myapp python:2 python your-daemon-or-script.py
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/python/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/python/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
rails/README.md
View File

@ -28,28 +28,14 @@ Then hit `http://container-ip:3000` in a browser. On the other hand, if you need
Then hit `http://localhost:8080` or `http://host-ip:8080` in a browser.
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/rails/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/rails/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
redis/README.md
View File

@ -40,28 +40,14 @@ Using this method means that there is no need for you to have a Dockerfile for y
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/redis/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/redis/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
ruby/README.md
View File

@ -27,28 +27,14 @@ For many single file projects, it may not be convenient to write a `Dockerfile`
docker run -it --rm --name my-running-script -v $(pwd):/usr/src/myapp -w /usr/src/myapp ruby ruby your-daemon-or-script.rb
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/ruby/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/ruby/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
ubuntu/README.md
View File

@ -75,28 +75,14 @@ If you run into any problems with this image, please check (and potentially file
* [saucy (13.10) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
* [trusty (14.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/ubuntu/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/ubuntu/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

28
wordpress/README.md
View File

@ -22,28 +22,14 @@ If you'd like to be able to access the instance from the host without the contai
Then, access it via `http://localhost:8080` or `http://host-ip:8080` in a browser.
# Issues and Contributing
# User Feedback
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
## Issues
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.
If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/wordpress/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
## Contributing
If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/wordpress/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
## Conventions
Fork the repository and make changes on your fork in a feature branch.
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
Commit messages should 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 force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.