Merge lp:~frankban/juju-gui/release-process-fixes into lp:juju-gui/experimental

[Francesco Banconi]

Fix release process documentation

And other minor changes, like text formatting fixes
and trailing spaces removal.

https://codereview.appspot.com/7039049/

[Francesco Banconi (frankban)]

Reviewers: mp+141738_code.launchpad.net,

Message:
Please take a look.

Description:
Fix release process documentation

And other minor changes, like text formatting fixes
and trailing spaces removal.

https://code.launchpad.net/~frankban/juju-gui/release-process-fixes/+merge/141738

(do not edit description out of merge proposal)

Please review this at https://codereview.appspot.com/7039049/

Affected files:
   A [revision details]
   M docs/process.rst

Index: [revision details]
=== added file '[revision details]'
--- [revision details] 2012-01-01 00:00:00 +0000
+++ [revision details] 2012-01-01 00:00:00 +0000
@@ -0,0 +1,2 @@
+Old revision:
<email address hidden>
+New revision:
<email address hidden>

Index: docs/process.rst
=== modified file 'docs/process.rst'
--- docs/process.rst 2012-12-21 02:16:06 +0000
+++ docs/process.rst 2013-01-03 11:45:17 +0000
@@ -106,8 +106,8 @@
  =====================================

  - Get a clean branch of the trunk:: ``bzr branch lp:juju-gui``.
-- If you are using a pre-existing branch, make sure it is up-to-date::
``bzr
- pull``.
+- If you are using a pre-existing branch, make sure it is up-to-date::
+ ``bzr pull``.
  - Verify that the top-most version in CHANGES.yaml specifies the expected
    version string. It should be bigger than the most recent version found
on
    https://launchpad.net/juju-gui/stable . If the most recent version
string
@@ -115,24 +115,25 @@

    * Decide what the next version number should be (see http://semver.org/)
and
      change "unreleased" to that value.
- * Commit to the branch with this checkin message: ``bzr commit -m 'Set
- version for release.'``
- * Push the branch directly to the parent (``bzr push`` should work).
+ * Commit to the branch with this checkin message:
+ ``bzr commit -m 'Set version for release.'``
+ * Push the branch directly to the parent (``bzr push :parent`` should
work).

-- Run the tests and verify they pass: ``make test-prod`` and then
- ``make test-debug``.
+- Run the tests and verify they pass: ``FINAL=1 make test-prod`` and then
+ ``FINAL=1 make test-debug``.
  - Create the tarball: ``FINAL=1 make distfile``. The process will end by
    reporting the name of the tarball it made.
  - In an empty temporary directory somewhere else on your system, expand the
    tarball: ``tar xvzf PATH_TO_TARBALL``
-- In that directory, start a server: ``python -m SimpleHTTPServer 8888``
+- In the ``build-prod`` directory, inside the uncompressed one, start a
server:
+ ``python -m SimpleHTTPServer 8888``
  - In Chrome and Firefox, QA the application. At the very least, load the
app,
    open the charm panel, go to an inner page, and make sure there are no
404s
    or Javascript errors in the console. We want a real QA script for the
    future.
  - For now, we will assume you would like to verify the release on the
    Launchpad staging server. As we become more confident with this process,
- this step may become unnecessary. In the checkout, run ``FINAL=1 make
+ this step may become unnecessary. In the branch, run ``FINAL=1 make
    dis...

[Nicola Larosa (teknico)]

Land with (small) changes.

https://codereview.appspot.com/7039049/diff/1/docs/process.rst
File docs/process.rst (right):

https://codereview.appspot.com/7039049/diff/1/docs/process.rst#newcode109
docs/process.rst:109: - If you are using a pre-existing branch, make
sure it is up-to-date::
No need for double colons in the two lines above.

https://codereview.appspot.com/7039049/diff/1/docs/process.rst#newcode128
docs/process.rst:128: - In the ``build-prod`` directory, inside the
uncompressed one, start a server:
s/inside/under/

https://codereview.appspot.com/7039049/diff/1/docs/process.rst#newcode183
docs/process.rst:183: - If you are using a pre-existing branch, make
sure it is up-to-date::
No need for double colons in the two lines above.

https://codereview.appspot.com/7039049/

[lp:~frankban/juju-gui/release-process-fixes]

297. By Francesco Banconi on 2013-01-03

Fixes per review

[Francesco Banconi (frankban)]

Thanks for the review Nicola.

https://codereview.appspot.com/7039049/diff/1/docs/process.rst
File docs/process.rst (right):

https://codereview.appspot.com/7039049/diff/1/docs/process.rst#newcode109
docs/process.rst:109: - If you are using a pre-existing branch, make
sure it is up-to-date::
On 2013/01/03 12:06:30, teknico wrote:
> No need for double colons in the two lines above.

Done.

https://codereview.appspot.com/7039049/diff/1/docs/process.rst#newcode128
docs/process.rst:128: - In the ``build-prod`` directory, inside the
uncompressed one, start a server:
On 2013/01/03 12:06:30, teknico wrote:
> s/inside/under/

Done.

https://codereview.appspot.com/7039049/diff/1/docs/process.rst#newcode183
docs/process.rst:183: - If you are using a pre-existing branch, make
sure it is up-to-date::
On 2013/01/03 12:06:30, teknico wrote:
> No need for double colons in the two lines above.

Done.

https://codereview.appspot.com/7039049/

[Francesco Banconi (frankban)]

Please take a look.

https://codereview.appspot.com/7039049/

[Francesco Banconi (frankban)]

Thanks Benji.

https://codereview.appspot.com/7039049/diff/4002/docs/process.rst
File docs/process.rst (right):

https://codereview.appspot.com/7039049/diff/4002/docs/process.rst#newcode123
docs/process.rst:123: ``FINAL=1 make test-debug``.
On 2013/01/03 14:01:52, benji wrote:
> Do you really need "FINAL=1" for tests? The last time I looked at the
Makefile
> it didn't change the way tests worked.

As discussed on IRC, I'll leave this workaround waiting for
https://bugs.launchpad.net/juju-gui/+bug/1095663 to be fixed.

https://codereview.appspot.com/7039049/diff/4002/docs/process.rst#newcode128
docs/process.rst:128: - In the ``build-prod`` directory, under the
uncompressed one, start a server:
On 2013/01/03 14:01:52, benji wrote:
> I can't parse this. The "under the uncompressed one" part is what
throws me
> off. I /think/ this is what it should say: "While still in the
directory where
> you extracted the tar file, change to the build-prod directory and
start a
> server:..."

> That might be better as two steps: one to change to the directory and
one to
> start the server.

Done.

https://codereview.appspot.com/7039049/diff/4002/docs/process.rst#newcode196
docs/process.rst:196: - In the ``build-prod`` directory, start a server:
On 2013/01/03 14:01:52, benji wrote:
> Should this line should be identical to the parallel step in the
stable release
> instructions (line 128)?

You are right, done.

https://codereview.appspot.com/7039049/

[lp:~frankban/juju-gui/release-process-fixes]

298. By Francesco Banconi on 2013-01-03

Changes per review.

[Francesco Banconi (frankban)]

*** Submitted:

Fix release process documentation

And other minor changes, like text formatting fixes
and trailing spaces removal.

R=teknico, benji
CC=
https://codereview.appspot.com/7039049

https://codereview.appspot.com/7039049/

=== modified file 'docs/process.rst'
--- docs/process.rst	2012-12-21 02:16:06 +0000
+++ docs/process.rst	2013-01-03 14:55:26 +0000
@@ -106,8 +106,8 @@
 =====================================
 
 - Get a clean branch of the trunk:: ``bzr branch lp:juju-gui``.
-- If you are using a pre-existing branch, make sure it is up-to-date:: ``bzr
-  pull``.
+- If you are using a pre-existing branch, make sure it is up-to-date:
+  ``bzr pull``.
 - Verify that the top-most version in CHANGES.yaml specifies the expected
   version string.  It should be bigger than the most recent version found on
   https://launchpad.net/juju-gui/stable .  If the most recent version string
@@ -115,24 +115,25 @@
 
   * Decide what the next version number should be (see http://semver.org/) and
     change "unreleased" to that value.
-  * Commit to the branch with this checkin message: ``bzr commit -m 'Set
-    version for release.'``
-  * Push the branch directly to the parent (``bzr push`` should work).
+  * Commit to the branch with this checkin message:
+    ``bzr commit -m 'Set version for release.'``
+  * Push the branch directly to the parent (``bzr push :parent`` should work).
 
-- Run the tests and verify they pass: ``make test-prod`` and then
-  ``make test-debug``.
+- Run the tests and verify they pass: ``FINAL=1 make test-prod`` and then
+  ``FINAL=1 make test-debug``.
 - Create the tarball: ``FINAL=1 make distfile``.  The process will end by
   reporting the name of the tarball it made.
 - In an empty temporary directory somewhere else on your system, expand the
   tarball: ``tar xvzf PATH_TO_TARBALL``
-- In that directory, start a server: ``python -m SimpleHTTPServer 8888``
+- While still in the directory where you extracted the tar file, change to the
+  build-prod directory and start a server: ``python -m SimpleHTTPServer 8888``.
 - In Chrome and Firefox, QA the application.  At the very least, load the app,
   open the charm panel, go to an inner page, and make sure there are no 404s
   or Javascript errors in the console.  We want a real QA script for the
   future.
 - For now, we will assume you would like to verify the release on the
   Launchpad staging server.  As we become more confident with this process,
-  this step may become unnecessary.  In the checkout, run ``FINAL=1 make
+  this step may become unnecessary.  In the branch, run ``FINAL=1 make
   dist``.  This will step you through signing the tarball, connecting
   to Launchpad, and uploading the release.
 
@@ -151,8 +152,9 @@
   SimpleHTTPServer 8888``, and do a quick double-check in the browser that it
   is what you expect.  Looking at juju-ui/version.js should also show you the
   version you expect.
-- This is a final release.  Consider asking others to verify the package on staging.
-- Now it is time for the actual, real release.  Head back to your checkout and
+- This is a final release.  Consider asking others to verify the package on
+  staging.
+- Now it is time for the actual, real release.  Head back to your branch and
   run ``FINAL=1 PROD=1 make dist``.  The computer will again walk you
   through the process.
 
@@ -165,32 +167,41 @@
 - Go to https://launchpad.net/juju-gui/stable and verify that you see
   a new release and a new download file.
 
+- Set the version back to ``unreleased`` by doing the following.
+
+  * Restore ``- unreleased:`` as most recent version string in CHANGES.yaml.
+  * Commit to the branch with this checkin message:
+    ``bzr commit -m 'Set version back to unreleased.'``
+  * Push the branch directly to the parent (``bzr push :parent`` should work).
+
 You are done!
 
 Checklist for Making a Developer Release
 ========================================
 
 - Get a clean branch of the trunk:: ``bzr branch lp:juju-gui``.
-- If you are using a pre-existing branch, make sure it is up-to-date::
+- If you are using a pre-existing branch, make sure it is up-to-date:
   ``bzr pull``.
 - Verify that the top-most version in CHANGES.yaml is "unreleased."
-- Run ``bzr revno``.  The revno should be bigger than the most recent release found on
-  `Launchpad <https://launchpad.net/juju-gui/trunk>`_.
-- Run the tests and verify they pass: ``make test``.
+- Run ``bzr revno``.  The revno should be bigger than the most recent release
+  found on `Launchpad <https://launchpad.net/juju-gui/trunk>`_.
+- Run the tests and verify they pass: ``make test-prod`` and then
+  ``make test-debug``.
 - Create the tarball: ``make distfile``.  It will end by reporting the name of
   the tarball it made.
 - In an empty temporary directory somewhere else on your system, expand the
   tarball: ``tar xvzf PATH_TO_TARBALL``.
-- Looking at juju-ui/version.js should show you a version string that combines
-  the value in the checkout's CHANGES.yaml with the checkout's revno.
-- In that directory, start a server: ``python -m SimpleHTTPServer 8888``
+- Looking at ``build-prod/juju-ui/version.js`` should show you a version string
+  that combines the value in the branch's CHANGES.yaml with the branch's revno.
+- While still in the directory where you extracted the tar file, change to the
+  build-prod directory and start a server: ``python -m SimpleHTTPServer 8888``.
 - In Chrome and Firefox, QA the application.  At the very least, load the app,
   open the charm panel, go to an inner page, and make sure there are no 404s
   or Javascript errors in the console.  We want a real QA script for the
   future.
 - For now, we will assume you would like to verify the release on the
   Launchpad staging server.  As we become more confident with this process,
-  this step may become unnecessary.  In the checkout, run ``make dist``.
+  this step may become unnecessary.  In the branch, run ``make dist``.
   This will step you through signing the tarball, connecting to
   Launchpad, and uploading the release.
 
@@ -209,7 +220,7 @@
   SimpleHTTPServer 8888``, and do a quick double-check in the browser that it
   is what you expect.  Looking at juju-ui/version.js should also show you the
   version you expect, as seen in the similar earlier step above.
-- Now it is time for the actual, real release.  Head back to your checkout and
+- Now it is time for the actual, real release.  Head back to your branch and
   run ``PROD=1 make dist``.  The computer will again walk you through the
   process.
 
@@ -228,14 +239,14 @@
 ======================================
 
 Within a checkout, a lightweight checkout, or a branch, you may run make as
-``NO_BZR=1 make [target]`` in order to prevent the Makefile from running 
+``NO_BZR=1 make [target]`` in order to prevent the Makefile from running
 any bzr commands, all of which access the parent branch over the network.
 Where bzr may have provided information such as the revno, sensible defaults
 are used instead.  As many of these bzr commands are used to populate
 variables regardless of the target, defining NO_BZR will have an effect on
 all targets, except dist, which will refuse to complete.
 
-- Note that this allows one to run any make target from the working copy, 
+- Note that this allows one to run any make target from the working copy,
   even if it is a lightweight checkout, by skipping steps that involve
   network access through bzr.  Because of this, make will assume that
   the revno is 0 and that the branch is clean and up to date without
@@ -279,9 +290,9 @@
 
   - Encourage but do not require each person to mention what card they plan to
     work on for the next 24 hours, if that has not already been discussed.
-  - Ask the person to mention any items that everyone should know: remind people
-    of reduced availability, request help such as code reviews or pair requests,
-    etc.
+  - Ask the person to mention any items that everyone should know: remind
+    people of reduced availability, request help such as code reviews or pair
+    requests, etc.
 
 Checklist for Running a Weekly Retrospective
 ============================================