After some discussion on a patch and in room with Doug,
we determined that we should make the guidance for release notes
more strongly suggest providing release notes in the same
patch as the changes being introduced.
Change-Id: Ifa8e8e9b01fafaa0a7e3e12b0052e4f8d5554e58
Since we added support for reno, document that submitters should
provide release notes with their changes. Rather than expecting
others to provide them at the end.
Change-Id: I787f37c9a748774b01cea08da38d91d62de96dd1
This patch switches horizon from using JSCS to using ESlint. It
adds the john papa style guides as an eslint plugin, and deactivates
additional linting rules so current cleanup efforts can focus on the
issues remaining from JSCS. Once that cleanup effort is complete,
we can switch our linting job to voting and move forward from there.
YAML for .eslintrc was chosen because the JSON specification does
not allow comments, and having comments (including rule links) will
make it easier to discuss linting changes.
Deactivated eslint rules have each been annotated with a # TODO
statement, so we can address them in the future. Links in the
documentation have been updated to new contributor guidelines, which
will be updated after this patch lands.
Linting may be executed by first installing npm dependencies using
`npm install`, and then executing `npm run lint` at any time in the
future. No python venv is required.
For clarification: We are switching to ESLint because JSCS explicitly
focuses on code-style, not on language use errors. For that purpose,
JSCS explicitly defers to JSHint, which due to the 'do no evil' license is
not usable. Since ESLint provides both the codestyle functionality, and
the language use checks, of both JSCS and JSHint, it was deemed the
only viable tool,
http://lists.openstack.org/pipermail/openstack-dev/2015-June/067030.html
Change-Id: Ib4c3f77f8cc3cdaa3c7558b7bc3a6d1299b6dcbe
Partially-Implements: blueprint jscs-cleanup
This patch is a first pass at reducing the levels of "tribal knowledge"
and making the AngularJS codebase more accessible. It details code
style, file structures, testing and translation.
Change-Id: I22e6e5627216739fc92a5c9a5b417c6c6b16476d
Closes-Bug: 1373310
This commit makes injectable names consistent to include
the module as a prefix. This reduces confusiong about
exactly which item is being injected.
It also simplifies the naming scheme for the Angular-based
API modules.
This is one step in a larger effort to restructure the Angular
source. See https://review.openstack.org/#/c/176152/ for the
full set of planned changes.
Change-Id: I87d4ff78b97950248442056ce3ce5af9177042ae
Partial-Bug: #1454880
This commit aligns module names with their directory
structure.
This is one step in a larger effort to restructure the Angular
source. See https://review.openstack.org/#/c/176152/ for the
full set of planned changes.
Change-Id: I3f48ebaef23d6249983f33b1a4710cc1fe3ef789
Partial-Bug: #1454880
This patch adds documentation recomending the John Papa Style guide.
Other patches may add automated style checks to JSCS.
Change-Id: Iae2cec88d8ea3c4ad570e1a1a42c5046bfef0dec
Implements: blueprint john-papa-style-guide
We want all our xstatic packages to be automatically published to PyPi
by Jenkins, not manually by individual packagers, if possible.
Also add a warning about the releases being permanent.
Change-Id: Ia800ac2bce5461a5051440f1a141de0d8cfeea8b
In a new section, titled performance, a requirement is added
for JavaScript code to limit the re-creation of objects in
the same scope. An example with jQuery is given with explanation.
Change-Id: I2f0d8392277f65384389d8d20154d645197050af
Partial-Bug: #1412971
A tool to allow pseudo translations to be created in order to identify
potential translation problems. To use the tool:
Make sure your English file is up to date:
./run_tests.sh --makemessages
Run the pseudo tool to create pseudo translations:
./run_tests.sh --pseudo de
Compile the catalog:
./run_tests.sh --compilemessages
Run your dev server. Log in and change to the language you pseudo translated.
It should look weird. More specifically, every translatable string is going
to start and end with a bracket and they are going to have some added
characters. For example, "Log In" will become "[~Log In~您好яшçあ]"
This is useful because you can inspect for the following:
- If you see a string in English it's not translatable. Should it be?
- If you see brackets next to each other that might be concatenation.
- If there is unexpected wrapping/truncation there might not be enough
space for translations
- If you see a string in the proper translated language, it comes from an
external source. (That's not bad, just sometimes useful to know)
- If you get new crashes, there is probably a bug. :-)
Implements blueprint: pseudo-translation-tool
Change-Id: If97754c2d4234b12b3d73616ff60527f6ad82d55
There is an extra 'that' in contributing.rst, which doesn't make
sense for the complete sentence. It should be omitted or written
in a different way as proposed in the bug description.
Change-Id: I4757c7948d0ee2701e985ee069ee6b2c5b9e769c
Closes-Bug: #1412617
Replace URLs for workflow documentation to appropriate parts of the
OpenStack Project Infrastructure Manual.
Change-Id: Ibf8fb2f6a1e8b0f80db6ab1180894c235046e785
As reported in the bug, the documentation needs to be updated with
a list of browsers we support. This patch adds faq entry and updates
information for contributing.
Change-Id: I6218194d031bc6b47a0fd13e5e11749df441398b
Closes-Bug: 1359246
To better facilitate the building and publishing of sphinx
documentation by Jenkins we are moving all openstack projects with
sphinx documentation to a common doc tree structure. Documentation
goes in project/doc and build results go in project/doc/build.
Change-Id: Ic523a716e4113198b777d6dc3db8bb8a729e7696