~jocave/checkbox/hybrid-amd-gpu-mods

« back to all changes in this revision

Viewing changes to cep/CEP-2.txt

  • Committer: Zygmunt Krynicki
  • Date: 2013-05-29 07:50:30 UTC
  • mto: This revision was merged to the branch mainline in revision 2153.
  • Revision ID: zygmunt.krynicki@canonical.com-20130529075030-ngwz245hs2u3y6us
checkbox: move current checkbox code into checkbox-old

This patch cleans up the top-level directory of the project into dedicated
sub-project directories. One for checkbox-old (the current checkbox and all the
associated stuff), one for plainbox and another for checkbox-ng.

There are some associated changes, such as updating the 'source' mode of
checkbox provider in plainbox, and fixing paths in various test scripts that we
have.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
=============================
2
 
Checkbox Enhancement Proposal
3
 
=============================
4
 
 
5
 
This proposal describes the new release process for internal Canonical
6
 
customers of Checkbox. 
7
 
 
8
 
Advantages
9
 
==========
10
 
 
11
 
* There is a tag associated with every release
12
 
* We can eventually generate source tarballs
13
 
* Tags from multiple components stored in lp:checkbox don't collide
14
 
* There is a way to iterate on release candidates if important issues are found
15
 
* All changes made in the release branch (including tags) end up in trunk
16
 
* The current CI system is involved to catch mistakes
17
 
 
18
 
New Process
19
 
===========
20
 
 
21
 
The new process is expressed as a series of shell commands and assumptions.
22
 
 
23
 
Assumptions
24
 
-----------
25
 
 
26
 
* We have lp:checkbox as ~/trunk and lp:checkbox/release as ~/release
27
 
* The process was followed before. This implies that lp:checkbox/release has
28
 
  no patches that are not already in lp:checkbox
29
 
* A number of new commands (not implemented) are available in the support
30
 
  directory as well as sub-commands of setup.py. Those are easy to emulate
31
 
  manually but should be implemented to fully automate the process.
32
 
 
33
 
Cutting the release
34
 
-------------------
35
 
 
36
 
Off-line steps, you can do them as many times as you like:
37
 
 
38
 
    ~$ bzr push -d trunk release
39
 
    # TODO: pick version of packaging branck to go along with this
40
 
    # do a test build, iterate if it fails
41
 
    ~$ cd release
42
 
    ~/release$ ./checkbox-old/setup.py bump-version-status --to=rc1
43
 
    ~/release$ bzr tag $(./checkbox-old/setup.py --name)-v$(./checkbox-old/setup.py --version)
44
 
 
45
 
On-line steps:
46
 
 
47
 
    ~/release$ bzr push lp:checkbox/release
48
 
    ~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing
49
 
 
50
 
Alternatively, instead of bzr push, propose the merge to launchpad,
51
 
auto-approve it and have tarmac do test package builds using the packaging
52
 
branch reference in support/packaging-revision
53
 
 
54
 
Fixing issues found in release candidates
55
 
-----------------------------------------
56
 
 
57
 
Off-line steps::
58
 
 
59
 
    ~/release$ while ./tree-broken; do
60
 
    > (cd bzr && vim .)
61
 
    > # Hack, cherry pick from trunk, fix locally, whatever
62
 
    > (cd release && bzr commit)
63
 
    > done
64
 
    ~/release$ ./checkbox-old/setup.py bump-version-status --to=next-rc
65
 
    ~/release$ bzr tag $(./checkbox-old/setup.py --name)-v$(./checkbox-old/setup.py --version)
66
 
 
67
 
On-line steps::
68
 
 
69
 
    ~/release$ bzr push lp:checkbox/release
70
 
    ~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing
71
 
    ~/release$ ./support/send-email --to=... --topic "Checkboc Release Candidate Available" <<EOM
72
 
    > The release candidate for the next checkbox release is available for
73
 
    > testing, please check and file bugs ... and target them to milestone ...
74
 
    > 
75
 
    > And we should improve this message one day
76
 
    > EOM
77
 
 
78
 
Alternatively, instead of bzr push, propose the merge to launchpad,
79
 
auto-approve it and have tarmac do test package builds using the packaging
80
 
branch reference in support/packaging-revision
81
 
 
82
 
Finalizing the release
83
 
----------------------
84
 
 
85
 
Off-line steps::
86
 
 
87
 
    ~/release$ ./checkbox-old/setup.py bump-version-status --to=final
88
 
    ~/release$ bzr tag $(./checkbox-old/setup.py --name)-v$(./checkbox-old/setup.py --version)
89
 
 
90
 
On-line steps::
91
 
 
92
 
    ~/release$ bzr push lp:checkbox/release
93
 
    ~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing
94
 
    ~/release$ ./support/ppa-copy \
95
 
    >   --from=ppa:~checkbox-dev/testing \
96
 
    >   --to=ppa:~checkbox-dev/stable \
97
 
    >   --packages=...
98
 
    ~/release$ ./support/send-email --to=... --topic "Next checkbox release" <<EOM
99
 
    > This is the next checkbox release.\
100
 
    > It has been published to the stable PPA.
101
 
    > 
102
 
    > And we should really improve this message one day
103
 
    > EOM
104
 
    ~/release$ bzr lp-propose-merge lp:checkbox -m "post-release merge back to trunk" --approve
105
 
 
106
 
Impact
107
 
======
108
 
 
109
 
If the new process is implemented correctly impact to our customers should be
110
 
minimal. We need to communicate the purpose of the release candidate releases
111
 
but apart from that the new process mirrors the effect of our current process