checkbox-dev team mailing list archive

[Brendan Donegan <brendan.donegan@xxxxxxxxxxxxx>]

On 07/02/14 17:12, Daniel Manrique wrote:
> > Cutting the release
> > -------------------
> >
> > Off-line steps, you can do them as many times as you like:
> >
> >      ~$ bzr push -d trunk release
> >      # TODO: pick version of packaging branck to go along with this
> >      # do a test build, iterate if it fails
>
> We need a standard way to do the test builds. It can be a separate proposal,
> it's orthogonal to this but they do intersect at some point.
>
>
> >      ~$ cd release
> >          ~/release$ ./checkbox-old/setup.py bump-version-status --to=rc1
> >          ~/release$ bzr tag $(./checkbox-old/setup.py --name)-v$(./checkbox-old/setup.py --version)
>
> can setup.py also do this second step? can we have a tool that does that? (it'll
> eventually fall off my bash history and I'll spend minutes chasing documentation
> when it should take seconds).

I think in general all of these steps should be encapsulated in 
manage_release as subcommands - so just say support/manage_release 
prepare and by the end of it have builds running in the PPA.

I also don't see the purpose of doing test builds on /release. It should 
mirror trunk. Things shouldn't be getting into trunk when they break 
builds. We should put a mechanism in place to ensure that.

> > On-line steps:
> >
> >      ~/release$ bzr push lp:checkbox/release
> >      ~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing
> >
> > Alternatively, instead of bzr push, propose the merge to launchpad,
> > auto-approve it and have tarmac do test package builds using the packaging
> > branch reference in support/packaging-revision
>
> We'd have to add a tarmac-build script for this, and amend the tarmac configs,
> right?
>
>
> > Fixing issues found in release candidates
> > -----------------------------------------
> >
> > Off-line steps::
> >
> >      ~/release$ while ./tree-broken; do
> >      > (cd bzr && vim .)
> >      > # Hack, cherry pick from trunk, fix locally, whatever
> >      > (cd release && bzr commit)
> >      > done
> >      ~/release$ ./checkbox-old/setup.py bump-version-status --to=next-rc
> >      ~/release$ bzr tag $(./checkbox-old/setup.py --name)-v$(./checkbox-old/setup.py --version)
> >
> > On-line steps::
> >
> >      ~/release$ bzr push lp:checkbox/release
> >      ~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing
> >      ~/release$ ./support/send-email --to=... --topic "Checkboc Release Candidate Available" <<EOM
> >      > The release candidate for the next checkbox release is available for
> >      > testing, please check and file bugs ... and target them to milestone ...
> >      >
> >      > And we should improve this message one day
> >      > EOM
> >
> > Alternatively, instead of bzr push, propose the merge to launchpad,
> > auto-approve it and have tarmac do test package builds using the packaging
> > branch reference in support/packaging-revision
> >
> > Finalizing the release
> > ----------------------
> >
> > Off-line steps::
> >
> >      ~/release$ ./checkbox-old/setup.py bump-version-status --to=final
> >      ~/release$ bzr tag $(./checkbox-old/setup.py --name)-v$(./checkbox-old/setup.py --version)
> >
> > On-line steps::
> >
> >      ~/release$ bzr push lp:checkbox/release
> >      ~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing
> >      ~/release$ ./support/ppa-copy \
> >      >   --from=ppa:~checkbox-dev/testing \
> >      >   --to=ppa:~checkbox-dev/stable \
> >      >   --packages=...

I hope this is just forgetting that manage_release publish command 
exists? There's no point in overgeneralising this - people will just end 
up forgetting packages etc. Also the PPA name is wrong - it's 
hardware-certification/public (but I'm aware this is probably a matter 
of 'something like' rather than the exact command to be run).

> >      ~/release$ ./support/send-email --to=... --topic "Next checkbox release" <<EOM
> >      > This is the next checkbox release.\
> >      > It has been published to the stable PPA.
> >      >
> >      > And we should really improve this message one day
> >      > EOM
> >      ~/release$ bzr lp-propose-merge lp:checkbox -m "post-release merge back to trunk" --approve
> >
> > Impact
> > ======
> >
> > If the new process is implemented correctly impact to our customers should be
> > minimal. We need to communicate the purpose of the release candidate releases
> > but apart from that the new process mirrors the effect of our current process
>
> This is OK. In practice we haven't had that many fixes resulting from testing a
> pre-release, but this makes that part of the process a bit more formal.