Updating docs to provide additional context
Upon reflection, we have determined that we need to provide a greater amount of context to those contributing in order to drive a higher quality end result. Change-Id: I8f0a24d929db78a45fdda2e30091aeb945c2802b
This commit is contained in:
parent
a693f674f2
commit
355513d76e
@ -11,12 +11,12 @@ For a highly abridged version, read on.
|
||||
Communicating
|
||||
-------------
|
||||
|
||||
Before you file a ticket or submit a pull request, its often helpful to chat
|
||||
with other developers. The #openstack-ironic channel is a good place to start,
|
||||
and if you don't have IRC (or would prefer email), openstack-dev@lists.openstack.org
|
||||
is the mailing list for all OpenStack projects. As the name implies, that mailing
|
||||
list is for all OpenStack development, so it's often harder to get attention on
|
||||
your particular issue.
|
||||
Before you file an Bug or new review set, its often helpful to chat with other
|
||||
developers. The #openstack-ironic channel is a good place to start, and if
|
||||
you don't have IRC (or would prefer email), openstack-dev@lists.openstack.org
|
||||
is the mailing list for all OpenStack projects. As the name implies, that
|
||||
mailing list is for all OpenStack development, so it's often harder to get
|
||||
attention on your particular issue.
|
||||
|
||||
-----------
|
||||
Filing Bugs
|
||||
@ -57,3 +57,44 @@ Once that's done, the development workflow is, roughly::
|
||||
From that point on, the link the git review command generated is
|
||||
the place to do final tweaks. When its approved, the code
|
||||
will be merged in automatically.
|
||||
|
||||
If you propose a new feature and are unable to complete it, please
|
||||
let the community know by commenting in the review set indicating
|
||||
that someone else is free to carry on your change. If the core
|
||||
reviewers observe reviews that are not being actively worked on,
|
||||
we are likely to inquire with you. If a review is untouched and the
|
||||
owner of the review is unreachable for a lengthy period of time,
|
||||
such as three to six months, the core reviewers may abandon the
|
||||
change as we do not utilize auto-abandon.
|
||||
|
||||
----------
|
||||
Code Style
|
||||
----------
|
||||
|
||||
Bifrost is a mix of Python, YaML, and bash thrown in for good measure.
|
||||
|
||||
The overall intent is to keep features, and changes simple to permit a user
|
||||
to easily understand and extend bifrost to meet their operational needs as
|
||||
we recognize needs may vary.
|
||||
|
||||
With this, we have a list of things that we would like people to keep in mind
|
||||
when contributing code.
|
||||
|
||||
1. Try to limit YaML to 79 characters per row, we understand this is not
|
||||
always possible, but please make an effort.
|
||||
2. Try to keep change sets as short and to the point as possible.
|
||||
3. Rather than pass key-value pair strings to Ansible modules, try to utilize
|
||||
key-value pair lists on a module command line. Example::
|
||||
|
||||
- name: "Stat file for x reason"
|
||||
stat:
|
||||
file: '/path/to/file'
|
||||
get_md5: no
|
||||
|
||||
4. Be clear and explicit with actions in playbooks and comments.
|
||||
5. Simplicity is favored over magic.
|
||||
6. Documentation should generally be paired with code changes as we feel
|
||||
that it is important for us to be able to release the master branch
|
||||
at any time.
|
||||
7. Documentation should always be limited to 79 characters per row.
|
||||
8. If you have any questions, ask in #openstack-ironic.
|
||||
|
12
README.rst
12
README.rst
@ -6,6 +6,18 @@ deploying a base image onto a set of known hardware using ironic. It
|
||||
provides modular utility for one-off operating system deployment with
|
||||
as few operational requirements as reasonably possible.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
* Installation of ironic in stand alone/noauth mode without other OpenStack
|
||||
components.
|
||||
* Deployment of an operating system to a known pool of hardware as
|
||||
a batch operation.
|
||||
* Testing and development of ironic in a standalone use case.
|
||||
|
||||
Use
|
||||
===
|
||||
|
||||
This is split into roughly three steps:
|
||||
|
||||
- **install**:
|
||||
|
Loading…
Reference in New Issue
Block a user