The .pdf documentation could not be build without errors because the source code of the documentation contained errors. In addition, there were other problems: - The readme section of the documentation was in .md format instead of .rst format. As a result, the created documentation did not look good. - The .html documentation used deprecated oslosphinx theme instead of openstackdocstheme. This patch fixes the above-mentioned problems and makes sure that the documentation is generated properly. Also, this patch updates nodejs4-docs to nodejs10-docs because the nodejs4-docs was using deprecated nodejs-npm-run-docs job .  https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/757101 Task: 35462 Depends-On: I738b833109e4caeb58bb391d79d6e63284462bd8 Change-Id: I921b15edda433c3e47456488da6d2bda07c34262
|8 months ago|
|doc||1 month ago|
|spec||5 years ago|
|.editorconfig||6 years ago|
|.eslintrc||5 years ago|
|.eslintrc-es2015||5 years ago|
|.gitignore||5 years ago|
|.gitreview||2 years ago|
|.npmrc||6 years ago|
|.zuul.yaml||1 month ago|
|CONTRIBUTING.rst||1 year ago|
|LICENSE||6 years ago|
|README.rst||1 month ago|
|bindep.txt||1 month ago|
|es2015.js||5 years ago|
|index.js||5 years ago|
|load-config.js||5 years ago|
|package.json||1 month ago|
|tox.ini||1 month ago|
OpenStack has a set of style guidelines for clarity. OpenStack is a very large code base, spanning dozens of git trees, with over a thousand developers contributing every 6 months. As such, common style helps developers understand code in reviews, move between projects smoothly, and overall make the code more maintainable.
Even though eslint permits overriding rules on a per-project basis, it should be the goal of every project to stay as close to the common guidelines as possible.
To add these rules to your project, follow these steps.
npm install --save-dev eslint eslint-config-openstack
extends: "openstack"to your
.eslintrcyaml file. If your project is using ES2015, add
If you would like to contribute, please follow OpenStack's contribution guidelines.
Patches that activate, deactivate, or modify rules, should only be merged if a consensus of reviewers is reached. In this case, consensus means at least five positive votes (+1 or +2), with no -1 votes. Cores may not override and/or ignore -1 votes.
Patches that upgrade eslint only require two core approvers to land. These patches must add new upstream rules in a deactivated state, and delete any deprecated rules.
Updates to policies and governance on this project require +2 votes from all direct cores on the project. Core votes from the parent OpenStack QA project are optional.
Cores should attempt to keep the list of extant patches small and managable. As such, they should talk to any author whose patch has failed to garner the necessary support, and has experienced one month of inactivity. Reasonable notice should be given to the author before a patch is abandoned.