clearlinux/docker
2
0
Fork 0
mirror of https://github.com/clearlinux/docker.git synced 2026-09-28 17:10:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

Cleanup: new project docs fix-ups (alternative)

Browse Source 
This cleans up the recently added project docs and
fixes some minor issues.

- remove inline styles where possible
- add redirects for renamed/replaced documents
- add styles for GitHub labels to match the style on GitHub
- fix minor markdown issues causing some code-blocks
  to be shown as text
- wrap the documents to 80-chars
- use 4 spaces in stead of tabs for identing and remove
  trailing whitespace/redundant blank lines
- optimized 'gordon' image

NOTE:
This alternative commit/PR re-introduces some inline
styles because the docs/base image has not yet been
updated for the current docs.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn
2015-03-07 23:40:34 +01:00
parent faa6fd40f4
commit efc625fcd0
11 changed files with 1203 additions and 958 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/sources/project/coding-style.md
+37 -20
View File
@@ -4,22 +4,26 @@ page_keywords: change, commit, squash, request, pull request, test, unit test, i
# Coding Style Checklist
This checklist summarizes the material you experienced working through [make a code contribution](/project/make-a-contribution) and [advanced contributing](/project/advanced-contributing). The checklist applies to code that is program code or code that is documentation code.
This checklist summarizes the material you experienced working through [make a
code contribution](/project/make-a-contribution) and [advanced
contributing](/project/advanced-contributing). The checklist applies to code
that is program code or code that is documentation code.
## Change and commit code
* Fork the `docker/docker` repository.
* Make changes on your fork in a feature branch. Name your branch `XXXX-something` where `XXXX` is the issue number you are working on.
* Make changes on your fork in a feature branch. Name your branch `XXXX-something`
where `XXXX` is the issue number you are working on.
* Run `gofmt -s -w file.go` on each changed file before
committing your changes. Most editors have plug-ins that do this automatically.
committing your changes. Most editors have plug-ins that do this automatically.
* Update the documentation when creating or modifying features.
* Commits that fix or close an issue should reference them in the commit message
`Closes #XXXX` or `Fixes #XXXX`. Mentions help by automatically closing the
issue on a merge.
`Closes #XXXX` or `Fixes #XXXX`. Mentions help by automatically closing the
issue on a merge.
* After every commit, run the test suite and ensure it is passing.
@@ -27,7 +31,8 @@ issue on a merge.
* Set your `git` signature and make sure you sign each commit.
* Do not add yourself to the `AUTHORS` file. This file is autogenerated from the Git history.
* Do not add yourself to the `AUTHORS` file. This file is autogenerated from the
Git history.
## Tests and testing
@@ -37,40 +42,52 @@ issue on a merge.
* Use existing Docker test files (`name_test.go`) for inspiration.
* Run <a href="../test-and-docs" target="_blank">the full test suite</a> on your branch before submitting a pull request.
* Run <a href="../test-and-docs" target="_blank">the full test suite</a> on your
branch before submitting a pull request.
* Run `make docs` to build the documentation and then check it locally.
* Use an <a href="http://www.hemingwayapp.com" target="_blank">online grammar
checker</a> or similar to test you documentation changes for clarity, concision,
and correctness.
checker</a> or similar to test you documentation changes for clarity,
concision, and correctness.
## Pull requests
* Sync and cleanly rebase on top of Docker's `master` without multiple branches
mixed into the PR.
mixed into the PR.
* Before the pull request, squash your commits into logical units of work using `git rebase -i` and `git push -f`.
* Before the pull request, 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.
* Include documentation changes in the same commit so that a revert would
remove all traces of the feature or fix.
* Reference each issue in your pull request description (`#XXXX`)
## Respond to pull requests reviews
* Docker maintainers use LGTM (**l**ooks-**g**ood-**t**o-**m**e) in PR comments to indicate acceptance.
* Docker maintainers use LGTM (**l**ooks-**g**ood-**t**o-**m**e) in PR comments
to indicate acceptance.
* Code review comments may be added to your pull request. Discuss, then make the
suggested modifications and push additional commits to your feature branch.
* Code review comments may be added to your pull request. Discuss, then make
the suggested modifications and push additional commits to your feature
branch.
* Incorporate changes on your feature branch and push to your fork. This automatically updates your open pull request.
* Incorporate changes on your feature branch and push to your fork. This
automatically updates your open pull request.
* Post a comment after pushing to alert reviewers to PR changes; pushing a change does not send notifications.
* Post a comment after pushing to alert reviewers to PR changes; pushing a
change does not send notifications.
* A change requires LGTMs from an absolute majority maintainers of an affected component. For example, if you change `docs/` and `registry/` code, an absolute majority of the `docs/` and the `registry/` maintainers must approve your PR.
* A change requires LGTMs from an absolute majority maintainers of an
affected component. For example, if you change `docs/` and `registry/` code,
an absolute majority of the `docs/` and the `registry/` maintainers must
approve your PR.
## Merges after pull requests
* After a merge, [a master build](https://master.dockerproject.com/) is available almost immediately.
* After a merge, [a master build](https://master.dockerproject.com/) is
available almost immediately.
* If you made a documentation change, you can see it at [docs.master.dockerproject.com](http://docs.master.dockerproject.com/).
* If you made a documentation change, you can see it at
[docs.master.dockerproject.com](http://docs.master.dockerproject.com/).