Update to Glance Contributor's docs
* add mention of Glance contrib guidelines to CONTRIBUTING.rst * update info about api-ref docs now being in-tree * add disallowed minor code change doc * database scripts, as agreed on at 2016-06-23 meeting * non-type-safe changes to tests Change-Id: I1e997efe72828d99626f5b7f2e2f7c96cae8da98
This commit is contained in:
parent
ed08411070
commit
d330e5a490
|
@ -1,7 +1,7 @@
|
|||
If you would like to contribute to the development of OpenStack,
|
||||
you must follow the steps in documented at:
|
||||
|
||||
http://docs.openstack.org/infra/manual/developers.html#development-workflow
|
||||
http://docs.openstack.org/infra/manual/developers.html#getting-started
|
||||
|
||||
Once those steps have been completed, changes to OpenStack
|
||||
should be submitted for review via the Gerrit tool, following
|
||||
|
@ -14,3 +14,8 @@ Pull requests submitted through GitHub will be ignored.
|
|||
Bugs should be filed on Launchpad, not GitHub:
|
||||
|
||||
https://bugs.launchpad.net/glance
|
||||
|
||||
Additionally, specific guidelines for contributing to Glance may be found in
|
||||
Glance's Documentation:
|
||||
|
||||
http://docs.openstack.org/developer/glance/contributing
|
||||
|
|
|
@ -35,10 +35,23 @@ which you may want to contribute:
|
|||
|
||||
* OpenStack API Reference
|
||||
|
||||
There are some Glance-related API quick-reference guides published by the
|
||||
OpenStack Documentation Team. Please see the README in their code repository
|
||||
for more information: https://github.com/openstack/api-site
|
||||
There's a "quick reference" guide to the APIs implemented by Glance:
|
||||
http://developer.openstack.org/api-ref/image/
|
||||
|
||||
The guide is generated from source files in the source code tree under
|
||||
``api-ref/source``. Corrections in spelling or typographical errors may be
|
||||
addressed directly by a patch. If you note a divergence between the API
|
||||
reference and the actual behavior of Glance, please file a bug before
|
||||
submitting a patch.
|
||||
|
||||
Additionally, now that the quick reference guides are being maintained by
|
||||
each project (rather than a central team), you may note divergences in format
|
||||
between the Glance guides and those of other teams. For example, some
|
||||
projects may have adopted an informative new way to display error codes. If
|
||||
you notice structural improvements that our API reference is missing, please
|
||||
file a bug. And, of course, we would also welcome your patch implementing
|
||||
the improvement!
|
||||
|
||||
Release Notes
|
||||
-------------
|
||||
|
||||
|
|
|
@ -13,6 +13,7 @@ Policies
|
|||
|
||||
blueprints
|
||||
documentation
|
||||
minor-code-changes
|
||||
.. bugs
|
||||
contributor-onboarding
|
||||
core-reviewers
|
||||
|
|
|
@ -0,0 +1,33 @@
|
|||
Disallowed Minor Code Changes
|
||||
=============================
|
||||
|
||||
There are a few types of code changes that have been proposed recently that
|
||||
have been rejected by the Glance team, so we want to point them out and explain
|
||||
our reasoning.
|
||||
|
||||
If you feel an exception should be made for some particular change, please put
|
||||
it on the agenda for the Glance weekly meeting so it can be discussed.
|
||||
|
||||
Database migration scripts
|
||||
--------------------------
|
||||
|
||||
Once a database script has been included in a release, spelling or grammar
|
||||
corrections in comments are forbidden unless you are fixing them as a part of
|
||||
another stronger bug on the migration script itself. Modifying migration
|
||||
scripts confuses operators and administrators -- we only want them to notice
|
||||
serious problems. Their preference must take precedence over fixing spell
|
||||
errors.
|
||||
|
||||
Tests
|
||||
-----
|
||||
|
||||
Occasionally someone proposes a patch that converts instances of
|
||||
``assertEqual(True, whatever)`` to ``assertTrue(whatever)``, or instances of
|
||||
``asertEqual(False, w)`` to ``assertFalse(w)`` in tests. Note that these are
|
||||
not type safe changes and they weaken the tests. (See the Python ``unittest``
|
||||
docs for details.) We tend to be very conservative about our tests and don't
|
||||
like weakening changes.
|
||||
|
||||
We're not saying that such changes can never be made, we're just saying that
|
||||
each change must be accompanied by an explanation of why the weaker test is
|
||||
adequate for what's being tested.
|
Loading…
Reference in New Issue