checkbox-dev team mailing list archive

[Zygmunt Krynicki <zygmunt.krynicki@xxxxxxxxxxxxx>]

Good point. I will collect all feedback and send an updated version of the
proposal.

Thanks
ZK
8 lut 2014 11:27 "Brendan Donegan" <brendan.donegan@xxxxxxxxxxxxx>
napisał(a):

> On 07/02/14 16:23, Zygmunt Krynicki wrote:> =============================
> > Checkbox Enhancement Proposal
> > =============================
> >
> > This proposal describes the new release process for internal Canonical
> > customers of Checkbox.
> >
> > Advantages
> > ==========
> >
> > * There is a tag associated with every release
> > * We can eventually generate source tarballs
> > * Tags from multiple components stored in lp:checkbox don't collide
> > * There is a way to iterate on release candidates if important issues
> are found
> > * All changes made in the release branch (including tags) end up in trunk
> > * The current CI system is involved to catch mistakes
> >
> > New Process
> > ===========
> >
> > The new process is expressed as a series of shell commands and
> assumptions.
> >
> > Assumptions
> > -----------
> >
> > * We have lp:checkbox as ~/trunk and lp:checkbox/release as ~/release
> > * The process was followed before. This implies that lp:checkbox/release
> has
> >    no patches that are not already in lp:checkbox
> > * A number of new commands (not implemented) are available in the support
> >    directory as well as sub-commands of setup.py. Those are easy to
> emulate
> >    manually but should be implemented to fully automate the process.
> >
> > 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
> >      ~$ cd release
> >          ~/release$ ./checkbox-old/setup.py bump-version-status --to=rc1
>
> This raises a question for me about how versions will work. Let's assume
> the above command gives us a version '0.17.6-rc1'. Will this version only
> appear when running setup.py version, or will it also appear in the version
> of the debian package version (like 0.17.5-rc1+bzr2005+201402070129~ubuntu12.04.1).
> If the latter is the case then should we really be keeping this version in
> two places - currently it appears in debian/changelog (in packaging) as
> well. We need to have a mechanism to make sure these don't get out of sync
> - either by setup.py reading from debian/changelog, or debian/changelog
> getting updated from setup.py version.
>
> >          ~/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
> >
> > 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
> >
> > 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=...
> >      ~/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
>
> --
> Mailing list: https://launchpad.net/~checkbox-dev
> Post to     : checkbox-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~checkbox-dev
> More help   : https://help.launchpad.net/ListHelp
>