[MERGE] Updated release documentation

[Jonathan Lange]

On Sat, Jun 13, 2009 at 8:24 AM, Bob Tanner<tanner at real-time.com> wrote:
> Brain-dump from myself on the knowledge I gained being the RM for 1.13 to
> 1.15.
>

Thanks! These mesh well with the gaps I found when getting the 1.16rc1
release out.

A few comments:

>  #. Push those changes to a bzr reposistory that is public and accessible on
> -   the Internet. PQM will pull from this repository when it attempts to merge
> -   your changes. Then submit those changes to PQM for merge into the
> -   appropriate release branch::
> +   the Internet. I recommend using Launchpad itself.  PQM will pull from this
> +   repository when it attempts to merge your changes. Then submit those changes to
> +   PQM for merge into the appropriate release branch::

That's what I recommend as well. However, it's often best to avoid the
first person in unattributed, group-owned documents like this. "We
recommend" or "It's recommended" are probably better.

> +   NOTE: Mirroring can take up to 10 minutes. If the pqm-submit fails with a 'lacks revision` error
> +         try the pqm-submit in a few minutes.
> +

Yeah, this sucks. The Launchpad Code team are working on lowering this
time. It's good to mention in the doc though.

> +   Recommendation, remove your ~/.bzr.log file. If there is a test suite
> +   failure you'll have a ready-to-upload log file for a bug report.
> +

Hmm. I generally find it easy enough to fetch stuff out of my .bzr.log.

> +   Recommendation, unset VISUAL and unset EDITOR to keep the test suite
> +   non-interactive. See https://bugs.launchpad.net/bzr/+bug/347130 and
> +   https://bugs.launchpad.net/bzr/+bug/326291 for details.
> +

I didn't notice any bugs wrt this.

> +   Recommendation, move your existing plugins out of the way. You do not want to pollute the testsuite.
> +   This should work (on linux) mv ~/.bazaar/plugins ~/.bazaar/plugins-old
> +

This is an interesting one. In a sense, it's good to see which plugins
break with this release, but perhaps tarball checking is not the right
time to do this.

In my own notes, I've put down "run the full test suite locally before
even beginning to release" partly to catch out-of-date plugins and the
like. Perhaps this is something to discuss separately.

> +   NOTE: I use virtualenv for check-dist-tarball, think pbuilder for linux, but for python. If there is interest, I can document
> +         how to setup virtualenv so you can get as many tests to pass for your platform as possible (example most people do
> +         not have MedusaFTP installed).

I guess this is a note for reviewers, rather than a note for people
reading the document. I'm personally not clear on the advantages of
this. Do you think it's worth doing?

Also, as noted elsewhere, I think that wrapping at 79 columns is
preferred (see http://doc.bazaar-vcs.org/latest/en/developer-guide/HACKING.html#code-layout).

Thanks again for writing this up.

jml