Update HACKING doc.

Update HACKING doc.

Reference the two different packaging recipes for trusty and beyond and for
the pre-trusty series.

The packaging branches are now two separate series:
lp:juju-quickstart/packaging and lp:juju-quickstart/packaging-pre-trusty.
Referencing them in the recipes is cleaner than using bare branch names.

Also add a QA step for environments.yaml generation.

https://code.launchpad.net/~bac/juju-quickstart/packaging-tweaks/+merge/222790

(do not edit description out of merge proposal)

[bac, 2014-06-11 12:39:45]

Please take a look.

[frankban, 2014-06-11 13:26:46]

Hi Brad,
thanks for the really nice updates to the documentation!

LGTM with a couple of suggestions.

https://codereview.appspot.com/103310043/diff/1/HACKING.rst
File HACKING.rst (right):

https://codereview.appspot.com/103310043/diff/1/HACKING.rst#newcode106
HACKING.rst:106: Repeat above on ec2.
What do you think about adding a step for verifying remote bundles with
simplified names are correctly deployed as well?
E.g. "juju quickstart bundle:mediawiki/single" or similar?

Also, it would be nice to also live test that the automatically generated local
environment works. To do this, we should temporarily remove the ~/.juju and
launch quickstart, selecting the first option.
This seems to me particularly important since it is likely the first thing users
new to Juju will do when installing quickstart.

The above can be done in a separate branch.

[bac, 2014-06-11 13:31:19]

Thanks for the review.  One question in-line.

https://codereview.appspot.com/103310043/diff/1/HACKING.rst
File HACKING.rst (right):

https://codereview.appspot.com/103310043/diff/1/HACKING.rst#newcode106
HACKING.rst:106: Repeat above on ec2.
On 2014/06/11 13:26:46, frankban wrote:
> What do you think about adding a step for verifying remote bundles with
> simplified names are correctly deployed as well?
> E.g. "juju quickstart bundle:mediawiki/single" or similar?


Does line 103 above not do what you want?

> Also, it would be nice to also live test that the automatically generated
local
> environment works. To do this, we should temporarily remove the ~/.juju and
> launch quickstart, selecting the first option.
> This seems to me particularly important since it is likely the first thing
users
> new to Juju will do when installing quickstart.

Good idea.  I'll add it to this branch.

> The above can be done in a separate branch.

[frankban, 2014-06-11 13:44:03]

On 2014/06/11 13:31:19, bac wrote:
> Thanks for the review.  One question in-line.
> 
> https://codereview.appspot.com/103310043/diff/1/HACKING.rst
> File HACKING.rst (right):
> 
> https://codereview.appspot.com/103310043/diff/1/HACKING.rst#newcode106
> HACKING.rst:106: Repeat above on ec2.
> On 2014/06/11 13:26:46, frankban wrote:
> > What do you think about adding a step for verifying remote bundles with
> > simplified names are correctly deployed as well?
> > E.g. "juju quickstart bundle:mediawiki/single" or similar?
> 
> 
> Does line 103 above not do what you want?

Oh, I missed that, you are right. I am not sure about the description of that
step: "Verify an environment that has already been bootstrapped is recogized and
the GUI is deployed::".
Perhaps another juju-quickstart call is missing below that, and the we need to
add something like "Verify quickstart can deploy remote bundles"?

[bac, 2014-06-11 14:56:05]

*** Submitted:

Update HACKING doc.

Reference the two different packaging recipes for trusty and beyond and for
the pre-trusty series.

The packaging branches are now two separate series:
lp:juju-quickstart/packaging and lp:juju-quickstart/packaging-pre-trusty.
Referencing them in the recipes is cleaner than using bare branch names.

Also add a QA step for environments.yaml generation.

R=frankban
CC=
https://codereview.appspot.com/103310043