39 lines
1.3 KiB
ReStructuredText
39 lines
1.3 KiB
ReStructuredText
==============
|
|
OpenDev Manual
|
|
==============
|
|
|
|
To build the manual, execute the following command::
|
|
|
|
$ tox
|
|
|
|
After running ``tox``, the documentation will be available for viewing
|
|
in HTML format in the ``doc/build/`` directory.
|
|
|
|
Terminology
|
|
===========
|
|
|
|
A note on terminology use in the manual:
|
|
|
|
This manual is in service of OpenDev, but does so primarily by
|
|
documenting how developers and project drivers can use the
|
|
infrastructure to accomplish their work.
|
|
|
|
We strive for consistent terminology that matches what developers and
|
|
our tooling use, even if some hosted projects use different
|
|
terminology.
|
|
|
|
Generally speaking these terms should be used as follows:
|
|
|
|
Project: The overall idea that there is a bunch of people working on a
|
|
bunch of code/text/etc. It can also refer to that actual collection
|
|
of code/text/etc (for instance, a project can be bundled up into a
|
|
tarball, and extracted into a directory). When a tool interacts with
|
|
that collection of code/text/etc, it interacts with the project (even
|
|
if it does so via the mechanism of git).
|
|
|
|
Repository: There are times when one needs to refer to the actual
|
|
source code management system of a project, that is, "git", and the
|
|
actual technical implementations of that SCM. In those cases where it
|
|
is important to distinguish the actual attributes of the SCM from the
|
|
project, it is useful to use the word "repository".
|