Revise release doc

* Revert html_theme to `default` since `classic` is not supported
in Sphinx 1.1.x
* Configure release to a generic account `pdc` instead of personal
* Improve release doc

JIRA: PDC-1014

.tito/releasers.conf

@@ -1,12 +1,12 @@
 [copr-pdc]
 releaser = copr_user.releasers.CoprUserReleaser
-project_name = pdc
+project_name = pdc/pdc
 upload_command = scp -i %(private_key)s %(srpm)s %(user)s@fedorapeople.org:/home/fedora/%(user)s/public_html/pdc_srpms
 remote_location = https://%(user)s.fedorapeople.org/pdc_srpms/
 
 [copr-pdc-test]
 releaser = copr_user.releasers.CoprUserReleaser
-project_name = pdc-test
+project_name = pdc/pdc-test
 upload_command = scp -i %(private_key)s %(srpm)s %(user)s@fedorapeople.org:/home/fedora/%(user)s/public_html/pdc_srpms
 remote_location = https://%(user)s.fedorapeople.org/pdc_srpms/
 builder.test = 1

docs/source/conf.py

@@ -106,7 +106,7 @@
 
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
-html_theme = 'classic'
+html_theme = 'default'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the

docs/source/release.rst

@@ -9,19 +9,19 @@ Versioning
 
 PDC versioning is based on `Semantic Versioning <http://semver.org/spec/v2.0.0.html>`_.
 
-And it's also RPM compatible.
+And it's RPM compatible.
 
 Given a version number MAJOR.MINOR.PATCH, increment the:
 
 #. MAJOR version when you make incompatible API changes,
-#. MINOR version when you add functionality in a backwards-compatible manner, and
-#. PATCH version when you make backwards-compatible bug fixes.
+#. MINOR version when you add functionality in a backwards-compatible manner,
+#. PATCH version when you make backwards-compatible bug fixing.
 
 Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
 
 #. A pre-release version MAY be denoted by appending a hyphen and an identifier immediately following the patch version.
 
-   Identifier MUST comprise only ASCII alphanumerics [0-9A-Za-z].
+   Identifier MUST be comprised and only with ASCII alphanumerics [0-9A-Za-z].
    Identifier MUST NOT be empty.
    Numeric identifier MUST NOT include leading zeroes.
    Pre-release versions have a lower precedence than the associated normal version.
@@ -30,7 +30,7 @@ Additional labels for pre-release and build metadata are available as extensions
 
 #. Build metadata MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch or a dot and a series of dot separated identifiers immediately following the pre-release version.
 
-   Identifiers MUST comprise only ASCII alphanumerics [0-9A-Za-z].
+   Identifiers MUST be comprise and only with ASCII alphanumerics [0-9A-Za-z].
    Identifiers MUST NOT be empty.
    Build metadata SHOULD be ignored when determining version precedence.
    Thus two versions that differ only in the build metadata, have the same precedence.
@@ -40,50 +40,52 @@ Additional labels for pre-release and build metadata are available as extensions
 Release Instruction
 -------------------
 
-In practice, we use `tito` to add git tag and do release including tag based releases and current HEAD based test releases.
+In practice, we use `tito` to add git tag and do release including tag based on releases and current HEAD based on test releases.
 
-A short instructions will be as simple as:
+.. NOTE:: `tito` version >= 0.6.2, install guide refer to: `https://github.com/dgoodwin/tito`
+
+A short instructions as:
 
 #. Tag: tito tag
 #. Test Build: tito build --rpm --offline
 #. Push: git push origin && git push origin $TAG
 #. Release: tito release copr-pdc/copr-pdc-test
 
-For each step, a more detailed version will be:
+For each step, more detail are:
 
 Tag
 ```
 
-Every time we are ready to have another release, we should add one git tag, with `tito`, we just need to::
+A new git tag need to be added before starting a new release::
 
     $ tito tag
 
 It will:
 
-- bump version or release, based on which `tagger`we're using, see `.tito/tito.props`;
-- help us create a annotated git tag based on our version;
-- update the spec file accordingly, generate changelog even.
+- bump version or release, based on which `tagger` is used, see `.tito/tito.props`;
+- create an annotated git tag based on our version;
+- update the spec file accordingly, generate changelog event.
 
 For more options about `tito tag`, run `tito tag --help`.
 
 Test Build
 ``````````
 
-After we have our release tag, we should do some build tests including source tarball checking, and rpm building testing.
+Once release tag is available, we can do some build tests including source tarball checking, and rpm building testing.
 
    ::
 
-    # generate source tarball
+    # generate local source tarball
     $ tito build --tgz --offline
 
-    # local rpm build
+    # generate local rpm build
     $ tito build --rpm --offline
 
-If everything goes well, you could go to next step and push your commit and tag to remote, otherwise you need to untag::
+If everything goes well, you could push your commit and tag to remote, otherwise the tag need to be undo::
 
     $ tito tag -u
 
-.. NOTE:: During developing, we could also generate test build at any time we want, it will based on current `HEAD` instead of latest tag.
+.. NOTE:: During developing, we could also generate test build any time, which will be based on current `HEAD` instead of latest tag.
 
   ::
 
@@ -93,7 +95,7 @@ If everything goes well, you could go to next step and push your commit and tag
 Push
 ````
 
-When you're happen with your builds, it's time to push commit and tag to remote.
+When you're happy with your build, it's time to push commit and tag to remote.
 
 ::
 
@@ -106,24 +108,30 @@ Thanks to `fedorapeople.org <https://fedorapeople.org/>`_ and `Fedora Copr <http
 use `tito` to release `PDC` as a `yum` or `dnf` repo.
 So that user could install `PDC` packages after enable the repo. [#]_
 
-.. NOTE:: Before doing any releases, you should make sure that you have account on both sites and also make sure that you could
+.. NOTE:: Before doing any release, make sure that you have account on both sites and also make sure that you could
   access to your fedorapeople space [#]_ and have enough permissions [#]_ to build `PDC` in `Copr`.
 
-  We need you to create a directory called `pdc_srpms/` under your fedorapeople space `public_html/` to hold all the uploaed
+  You need to create a directory called `pdc_srpms/` under your fedorapeople space `public_html/` to hold all the uploaded
   srpms.
 
-  `copr-cli` will be used, so please `sudo yum/dnf install copr-cli` and configure it. [#]_
+  `copr-cli` will be used, installed by `sudo yum/dnf install copr-cli` and configure it. [#]_
+
+Currently there are two projects in `Copr`: `pdc` for all tag based releases and `pdc-test` for test builds. We have two
+release targets in `tito`, `copr-pdc` is for `pdc` in `Copr` and `copr-pdc-test` is for `pdc-test` respectively.
 
-Currently we have two projects in `Copr`, `pdc` for all tag based releases and `pdc-test` for test builds. We have two
-release targets in `tito`, `copr-pdc` is for `pdc` in `Copr` and `copr-pdc-test` is for `pdc-test`, respectively.
+Request as `Builder` for projects `pdc/pdc-test` and `pdc/pdc`, wait until admin approves.
 
 After all setup, release with `tito`::
 
     $ tito release copr-pdc
     # or
     $ tito release copr-pdc-test
 
-Go and grab a cup of tea or coffee, after a minute or two the release build result will come out then.
+Go and grab a cup of tea or coffee, the release build will be come out soon ::
+
+    # test builds: `https://copr.fedoraproject.org/coprs/pdc/pdc-test/builds/`
+    # tag based builds: `https://copr.fedoraproject.org/coprs/pdc/pdc/builds/`
+
 
 .. [#] https://fedorahosted.org/copr/wiki/HowToEnableRepo
 .. [#] http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#Accessing_Your_fedorapeople.org_Space