Merge lp:~vila/brz/prepare-3.0.0 into lp:brz

Proposed by Vincent Ladeuil on 2018-09-14
Status: Merged
Approved by: Vincent Ladeuil on 2018-09-14
Approved revision: no longer in the source branch.
Merge reported by: The Breezy Bot
Merged at revision: not available
Proposed branch: lp:~vila/brz/prepare-3.0.0
Merge into: lp:brz
Diff against target: 375 lines (+53/-130)
3 files modified
doc/developers/releasing.txt (+51/-128)
doc/en/_templates/index.html (+1/-1)
doc/en/index.txt (+1/-1)
To merge this branch: bzr merge lp:~vila/brz/prepare-3.0.0
Reviewer Review Type Date Requested Status
Jelmer Vernooij 2018-09-14 Approve on 2018-09-14
Review via email: mp+354935@code.launchpad.net

Commit message

Start preparing brz releases.

Description of the change

First pass on the doc/developers/releasing.txt to simplify breezy releases.

I haven't documented the alpha release process so we can discuss it first, a few things appeared while I was reviewing the bzr process:

- we should have defined a 3.0.0b1 milestone rather than using the 3.0.0 one
- we use breezy rather than brz for pypi project name (sounds ok to me but I haven't tested yet)
- we should think about releasing the doc somewhere that is not doc.bazaar.canonical.com (the bzr setup has always been messy and probaly completely dead as we speak)
- Is there really a <email address hidden> list ?

For the alpha release I think we should:
- upload a tarball to lp
- upload a tarball to pypi
- mail <email address hidden>

To post a comment you must log in.
Jelmer Vernooij (jelmer) wrote :

There is indeed no packagers list yet, I think we just added up with a reference to that because of overzealous s/bzr/brz/ replacing. :)

I'd like to publish all the documentation on doc.breezy-vcs.org somewhere, since the docs on doc.bazaar.canonical.com will be out of date.

Publishing the alpha to lp, pypi and mailing to the Bazaar list seems reasonable to me. Perhaps we can also add a post on the homepage?

review: Approve
lp:~vila/brz/prepare-3.0.0 updated on 2018-09-14
7110. By Jelmer Vernooij on 2018-09-14

Drop python3.flapping.

Merged from https://code.launchpad.net/~jelmer/brz/drop-flapping/+merge/353460

7111. By Jelmer Vernooij on 2018-09-14

Drop the whitelist for Python 3 now that all tests are passing.

Merged from https://code.launchpad.net/~jelmer/brz/python3-drop-whitelist/+merge/353755

7112. By Vincent Ladeuil on 2018-09-14

Start preparing brz releases.

Merged from https://code.launchpad.net/~vila/brz/prepare-3.0.0/+merge/354935

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'doc/developers/releasing.txt'
2--- doc/developers/releasing.txt 2017-11-11 12:51:45 +0000
3+++ doc/developers/releasing.txt 2018-09-14 09:41:35 +0000
4@@ -23,15 +23,8 @@
5 Preconditions
6 =============
7
8-#. PQM access rights (or you won't be able to land any change)
9-
10-#. Download the pqm plugin and install it into your ``~/.bazaar/plugins``::
11-
12- brz branch lp:brz-pqm ~/.bazaar/plugins/pqm
13-
14-#. Alternatively, you can download and install ``lp:hydrazine`` (the main
15- difference is that hydrazine requires the branch to land to be hosted on
16- launchpad).
17+#. Be a member of https://launchpad.net/~brz (or you won't be able to land
18+ any change)
19
20 What do we release
21 ==================
22@@ -39,7 +32,7 @@
23 In this document, we're talking about source releases only, packages and
24 installers are built from this but we won't talk about them here.
25
26-Every release is part of a series, ``brz-2.4.1`` is part of series ``2.4``.
27+Every release is part of a series, ``brz-3.0.0`` is part of series ``3.0``.
28
29 We do two different kind of releases: the betas releases and the stable
30 releases for a given series.
31@@ -63,18 +56,7 @@
32 When do we relase ?
33 ===================
34
35-As of July 2011, we maintain four series (and one that is about to be EOLed).
36-Concurrently releasing them all at the same time makes it harder to shorten
37-the delay between the source availability and the package building longer
38-than necessary (we delay the official announcement until most of our users
39-can install the new release).
40-
41-In order to continue to do time-based releases, we need to plan the
42-releases by series to minimize the collisions. In the end, it's the Release
43-Manager call to decide whether he prefers to do all releases at once
44-though, so the rules presented here are a conservative approach.
45-
46-We want to respect the following rules:
47+As of September 2018, we maintain a single series: 3.0.
48
49 #. as much as possible releases should not disturb development, and
50 ongoing development should not disturb releases,
51@@ -103,12 +85,6 @@
52 Release Manager is free to ignore this (get in touch with packagers
53 though),
54
55-#. the series are aligned with Ubuntu releases for convenience since we
56- create a new series every 6 months. This means that we support the
57- stable series for 18 months. Note that we also propose the most recent
58- stable series via the stable PPA but that the SRU processs allow us to
59- reach a wider audience.
60-
61 At the start of a series cycle
62 ==============================
63
64@@ -121,21 +97,21 @@
65 expected dates. Only the milestone associated to the next release in
66 this series should be left active to avoid clutter when targeting bugs.
67
68-#. If you made a new series, you will need to create a new pqm-controlled
69- branch for this release series. This branch will be used only from the
70- first non-beta release onwards. It needs to be created by a Canonical
71- sysadmin (ask the core devs for instructions or to do it for you).
72+#. If you made a new series, you will need to create a new branch for this
73+ release series. This branch will be used only from the first non-beta
74+ release onwards. It needs to be created by a https://launchpad.net/~brz
75+ member (ask the core devs for instructions or to do it for you).
76
77 #. Start a new release-notes file::
78
79 cd doc/en/release-notes
80- cp series-template.txt brz-x.y.txt # e.g. brz-2.3.txt
81- brz add brz-x.y.txt
82+ cp series-template.txt brz-x.y.txt # e.g. brz-3.1.txt
83+ brz add brz-3.1.txt
84
85 #. Start a new whats-new file::
86
87 cd doc/en/whats-new
88- cp template.txt brz-x.y.txt # e.g. brz-2.6.txt
89+ cp template.txt brz-x.y.txt # e.g. brz-3.1.txt
90 brz add brz-x.y.txt
91
92 #. Update ``doc/en/index.txt`` to point to the new whats-new file.
93@@ -162,20 +138,7 @@
94 Note that you will generally reuse the same branch for all releases in a
95 given series.
96
97-#. Configure pqm-submit for this branch, with a section like this (where
98- ``x.y`` is the series for your release). **Or use hydrazine for easier
99- setup** ``~/.bazaar/locations.conf``::
100-
101- [/home/mbp/brz/x.y-dev]
102- pqm_email = Canonical PQM <pqm@bazaar-vcs.org>
103- submit_branch = http://bazaar.launchpad.net/~brz-pqm/brz/x.y
104- parent_branch = http://bazaar.launchpad.net/~brz-pqm/brz/x.y
105- public_branch = http://bazaar.example.com/x.y-dev
106- submit_to = bazaar@lists.canonical.com
107- smtp_server = mail.example.com:25
108-
109- Please see <http://doc.bazaar.canonical.com/developers/HACKING.html#an-overview-of-pqm>
110- for more details on PQM
111+#. Add a landing job for the release branch at https://ci.breezy-vcs.org/
112
113 #. Update the version number in the ``brz`` script, and the
114 ``breezy/__init__.py`` file::
115@@ -193,7 +156,8 @@
116 <https://launchpad.net/brz/x.y/x.y.z/+edit> allows you to toggle the
117 active flag.
118
119-#. Commit this and send it to PQM.
120+#. Commit this and make a proposal against the release branch. Self approve
121+ it (you're the release manager).
122
123
124 Doing a particular release
125@@ -208,17 +172,19 @@
126 found at <https://launchpad.net/brz/+milestone/x.y.z>.
127
128 #. Merge into your branch all previous stable series fixes that haven't been
129- merged yet. For example, if you're releasing 2.6.x, make sure the fixes
130- on 2.5, 2.4, 2.3, etc have already been merged up::
131+ merged yet. For example, if you're releasing 3.2.x, make sure the fixes
132+ on 3.1, 3.0 have already been merged up::
133
134- brz merge lp:brz/2.4
135+ brz merge lp:brz/3.1
136
137 and commit that merge in its own commit. This should happen only if the
138 devs landing changes in previous releases forgot to merge them up. Since
139 this can slow down the freeze, feel free to gently remind them about
140 their duties ;) If you feel unsafe resolving the conflicts or it's too
141 time consuming, contact the related devs and skip this merge.
142-
143+
144+ Alternatively, think about automating these merges.
145+
146 #. In the release branch, update ``version_info`` in ``./breezy/__init__.py``.
147 Make sure the corresponding milestone exists.
148 Double check that ./brz ``_script_version`` matches ``version_info``. Check
149@@ -226,30 +192,30 @@
150
151 For beta releases use::
152
153- version_info = (2, 6, 0, 'beta', SERIAL)
154-
155- For instance 2.6b1::
156-
157- version_info = (2, 6, 0, 'beta', 1)
158+ version_info = (3, 0, 0, 'beta', SERIAL)
159+
160+ For instance 3.0b1::
161+
162+ version_info = (3, 0, 0, 'beta', 1)
163
164 For stable releases use::
165
166- version_info = (2, 6, 0, 'final', 0)
167+ version_info = (3, 0, 0, 'final', 0)
168
169 #. Update the ``./doc/en/release-notes/`` section for this release.
170
171 Check that all news entries related to this release have been added in
172- the right section. For example, if you're releasing 2.6b2, the following
173- command should display a a single chuk diff for the 2.6b2 release::
174+ the right section. For example, if you're releasing 3.0b3, the following
175+ command should display a a single chuk diff for the 3.0b3 release::
176
177- brz diff -rbrz-2.6b2.. doc/en/release-notes/brz-2.6.txt
178+ brz diff -rbrz-3.0b2.. doc/en/release-notes/brz-3.0.txt
179
180 Fill out the date and a description of the release under the existing
181 header (the diff above will help you summarizing). If there isn't one,
182 follow the instructions above for using the ``release-template.txt`` file
183 and remind people that they should document their changes there ;)
184
185- See *2.6b1* or similar for an example of what this looks like.
186+ See *3.0b1* or similar for an example of what this looks like.
187
188 #. Add or check the summary of the release into the "What's New" document.
189
190@@ -362,26 +328,21 @@
191
192 #. Tag the new release::
193
194- brz tag brz-2.6.0
195+ brz tag brz-3.0.0
196
197-#. Push those changes to a brz branch that is public and accessible on the
198- Internet. PQM will pull from this branch when it attempts to merge your
199- changes. Then submit those changes to PQM for merge into the appropriate
200- release branch::
201+#. Push those changes to a brz branch and make a merge proposal::
202
203 brz push
204- brz pqm-submit -m "(vila) Release 2.6.0 (Vincent Ladeuil)"
205+
206+ Use a commit message formatted like::
207+
208+ (vila) Release 3.0.0 (Vincent Ladeuil)
209
210 Note that ``brz push`` should mention updating one tag (which you just
211 created). If it doesn't, double-check that you created (and pushed) this
212 tag.
213
214- Or with hydrazine::
215-
216- brz lp-propose -m "Release 1.14" --approve lp:brz/1.14
217- feed-pqm brz
218-
219-#. When PQM succeeds, pull down the master release branch.
220+#. Once the merge proposal has landed, pull down the master release branch.
221
222
223 Making the source tarball
224@@ -403,19 +364,10 @@
225 ``BRZ_DISABLE_PLUGINS`` or ``BRZ_PLUGIN_PATH=-site`` to disable one or
226 all plugins.
227
228- Until <http://pad.lv/839461> is fixed, you may encounter issues if you
229- cut a release for old stable branches (<= 2.2) and use a more recent
230- OS/distro. If that's the case, check the bug status and use the following
231- workaround if no fix is available::
232-
233- export TTPATH=<local branch of lp:testtools -r 0.9.2>
234- export SUPATH=<local branch of lp:subunit -r 0.0.6>
235- PYTHONPATH=$TTPATH:$SUPATH/python PATH=$SUPATH/filters:${PATH} BRZ_PLUGIN_PATH=-site make check-dist-tarball PYTHON=python2.6 | subunit2pyunit
236-
237- Remember that PQM has just tested everything too, this step is
238- particularly testing that the cython extensions, which are updated
239- by your local cython version when you run make dist, are in good
240- shape.
241+ Remember that this branch has already been tested on
242+ https://ci.breezy-vcs.org, this step is particularly testing that the
243+ cython extensions, which are updated by your local cython version when
244+ you run make dist, are in good shape.
245
246
247 Publishing the source tarball
248@@ -464,7 +416,7 @@
249
250 #. ``lp:brz/x.y`` needs to be opened for the next *release* ``x.y.0`` in the
251 series. Since this is first real use of ``lp:brz/x.y``, this is also the
252- deadline for the PQM branch to be created.
253+ deadline for the https://ci.breezy-vcs.org/ landing job to be created.
254
255 Both are important as ``lp:brz`` should remain open so any change can be
256 landed, ``lp:brz/x.y`` on the other hand should be ready to receive bug
257@@ -478,12 +430,8 @@
258
259 #. Open ``lp:brz`` for ``x.(y+1)``
260
261-#. Create or update the ``x.y`` PQM branch based on whatever revision you
262- want to release. Since it takes time to create the PQM branch for the new
263- series you should plan to get it created a few days before you need it
264- and seed it with the revision from trunk you want to base your release of
265- (ask a LOSA for pulling this revision from trunk and pushing it to the
266- series branch (``lp:brz/x.y``) when you're ready).
267+#. Create https://ci.breezy-vcs.org/ landing job and/or update the
268+ ``lp:brz/x.y`` branch based on whatever revision you want to release.
269
270 #. Release ``x.y.0`` from ``lp:brz/x.y``
271
272@@ -606,41 +554,14 @@
273 mentioning the milestone URL <https://launchpad.net/brz/+milestone/x.y.z>
274 so people get an easy access to details.
275
276-#. Announce on https://freecode.com/projects/bazaar-vcs
277-
278- This should be done for beta releases and stable releases. If you do not
279- have a Freecode account yet, ask one of the existing admins.
280-
281- The purpose here is to point users to the latest stable release
282- (i.e. SRUs are excluded) while still publishing announcements for beta
283- releases.
284-
285- There are several kinds of modifications that could be done there via the
286- ``Administration`` box in the lower right area of the page:
287-
288- * Edit the project: This is where most of the URLs proposed in the
289- ``Links`` box are edited. This should rarely change except for the URLs
290- related to the latest stable release.
291-
292- * New announcement: When doing a release, put the summary of the release
293- (you can't embed URLs there, the moderation staff remove them). Users
294- can still access the releases notes via the ``Release Notes`` URL in
295- the ``Links`` box in the upper right area of the page. When doing the
296- first stable release in a series, delete the ``Unstable installers``
297- <https://launchpad.net/brz/x.y/x.ybn> and ``Unstable source tarball``
298- <http://launchpad.net/brz/x.y/x.ybn/+download/brz-x.ybn.tar.gz>
299- links. Conversely, when creating the first beta in a development
300- series, create these links again. Check all links when doing other
301- kinds of release.
302-
303 #. Update `<http://en.wikipedia.org/wiki/Breezy_(software)>`_ -- this should
304 be done for the stable and beta releases.
305
306-#. Update the python package index: <http://pypi.python.org/pypi/brz>
307+#. Update the python package index: <http://pypi.python.org/pypi/breezy>
308
309 From the tarball created and tested earlier ::
310
311- twine upload -s ../brz-2.7.0.tar.gz
312+ twine upload -s ../breezy-3.0.0.tar.gz
313
314 Remember to check the results afterward -- this should be done for
315 stable releases but not for beta releases nor SRUs.
316@@ -666,13 +587,13 @@
317 password:<password on testpypi>
318 repository = https://testpypi.python.org/pypi
319
320- Registering the brz project if doesn't exist is achieved with::
321+ Registering the breezy project if doesn't exist is achieved with::
322
323 python setup.py -r https://testpypi.python.org/pypi register
324
325 Uploading is done with::
326
327- twine upload -r testpypi -s ../brz-2.7.0.tar.gz
328+ twine upload -r testpypi -s ../breezy-3.0.0.tar.gz
329
330 To be able to upload the release you must create an account on
331 <http://pypi.python.org/pypi> and have one of the existing owners of the
332@@ -688,7 +609,7 @@
333 has its own release-notes file, but double-check.
334
335 If it's not already done, advance the version number in ``brz`` and
336-``breezy/__init__.py``. Submit this back into pqm for brz.dev.
337+``breezy/__init__.py``. File a merge proposal against ``lp:brz``.
338
339 As soon as you change the version number in trunk, make sure you have
340 created the corresponding milestone to ensure the continuity in bug
341@@ -714,6 +635,8 @@
342 Getting the release into Ubuntu
343 -------------------------------
344
345+/!\ Nothing in this section has been validated for breezy yet.
346+
347 (Feel free to propose or add new sections here about what we should do to
348 get brz into other places.)
349
350
351=== modified file 'doc/en/_templates/index.html'
352--- doc/en/_templates/index.html 2017-06-02 23:47:28 +0000
353+++ doc/en/_templates/index.html 2018-09-14 09:41:35 +0000
354@@ -24,7 +24,7 @@
355 <span class="linkdescr">a detailed log of changes</span>
356 </p>
357 <p class="biglink"><a class="biglink" href="{{ pathto("upgrade-guide/index") }}">Upgrade Guide</a><br/>
358- <span class="linkdescr">moving to Breezy 2.x</span>
359+ <span class="linkdescr">moving to Breezy 3.x</span>
360 </p>
361 <p class="biglink"><a class="biglink" href="{{ pathto("user-reference/index") }}">User Reference</a><br/>
362 <span class="linkdescr">all the gory details</span>
363
364=== modified file 'doc/en/index.txt'
365--- doc/en/index.txt 2016-02-01 19:26:41 +0000
366+++ doc/en/index.txt 2018-09-14 09:41:35 +0000
367@@ -10,7 +10,7 @@
368 .. toctree::
369 :maxdepth: 1
370
371- whats-new/whats-new-in-2.8
372+ whats-new/whats-new-in-3.0
373 user-guide/index
374 tutorials/index
375 quick-reference/index

Subscribers

People subscribed via source and target branches