Bazaar

Merge lp:~mbp/bzr/doc into lp:bzr

  1. doc
  2. Merge into bzr.dev
Proposed by Martin Pool
Status: Merged
Merged at revision: not available
Proposed branch: lp:~mbp/bzr/doc
Merge into: lp:bzr
Diff against target: 122 lines (+31/-47)
2 files modified
doc/developers/cycle.txt (+30/-46)
doc/en/_templates/index.html (+1/-1)
To merge this branch: bzr merge lp:~mbp/bzr/doc
Reviewer Review Type Date Requested Status
bzr-core Pending
Review via email: mp+16997@code.launchpad.net
To post a comment you must log in.
Revision history for this message
Martin Pool (mbp) wrote :

Following comments in <https://code.edge.launchpad.net/~spiv/bzr/annotate-objectnotlocked-496590/+merge/16945> this

 * gives some more tips on reviewing for the stable branch
 * removes outdated text about proposing a six month cycle
 * adds a hyperlink

Revision history for this message
Martin Pool (mbp) wrote :

i meant to say, following https://code.edge.launchpad.net/~jameinel/bzr/2.0.4-unregister-mem-trans/+merge/16980

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'doc/developers/cycle.txt'
2--- doc/developers/cycle.txt 2009-12-14 08:41:19 +0000
3+++ doc/developers/cycle.txt 2010-01-08 00:46:12 +0000
4@@ -21,49 +21,6 @@
5 * `Releasing Bazaar <releasing.html>`_ -- the process for actually making
6 a release or release candidate.
7
8-The Problem Situation
9-*********************
10-
11-Bazaar makes a release every month, preceded by a one-week
12-release-candidate test.
13-
14-In any release we may fix bugs, add formats, change the default format,
15-improve performance, add new commands or change command line behaviour,
16-change the network protocol, or deprecate APIs. We sometimes also
17-introduce new bugs, regress existing behaviour or performance, remove
18-existing features or formats, or break behaviour or APIs depended upon by
19-plugins, external programs or users.
20-
21-Some users are happy upgrading every month and consider the overall
22-positive balance of changes is worth some amount of churn. But there are
23-some serious problems:
24-
25-* You cannot get bug fixes without also getting disruptive changes.
26-
27-* Bazaar is seen as unstable.
28-
29-* Many releases cause some plugin breakage.
30-
31-* One month is not a very long window for dependent programs or systems
32- to catch up to changes in Bazaar before the release goes out of date.
33-
34-* There's no clear indication to distributions which version they should
35- package.
36-
37-* If people (or their distributions) just pick an arbitrary version, they
38- may all be on different arbitrary versions, therefore they will have
39- different behaviour and different bugs, and sometimes interoperation
40- problems.
41-
42-* Any effort we, or distributors, wanted to put into backporting fixes
43- would be dissipated across many possible backport target releases.
44-
45-* When in the past we've tried either stalling releases for particular
46- features, or having trunk frozen for some weeks, it causes churn and
47- waste. People rush features in, or already landed features wait a long
48- time to be released, or branches go out of date because they cannot
49- land.
50-
51
52 The Process
53 ************
54@@ -421,25 +378,52 @@
55
56 * Users like it.
57
58+After doing this for the 2.0 cycle (September 2009 through to early
59+2010), it seems to be going well.
60+
61
62 Reviewing for the Stable Branch
63 *******************************
64
65+These are guidelines and can be interpreted case-by-case.
66+
67 * All changes to the stable branch should fix a bug, even if you would not
68 normally file a bug for the change. The bug description should if at
69 all possible explain how to manually verify the bug in a way that will
70 fail before and pass after the change. (These are requirements for the
71 SRU process.)
72
73-* The change should be reasonably small and conservative. Be extra
74- careful of things that could break on other platforms or locales.
75+* The change should be reasonably small and conservative.
76+
77+* Remember that the patch will be read during the SRU
78+ process and so keeping the patch small is useful even beyond keeping the
79+ logical changes small. Avoid doing mechanical bulk changes on the
80+ stable branch.
81+
82+* Use particular care for things that may behave differently across
83+ platforms, encodings or locales. It's harder to thoroughly test these
84+ things before a release.
85+
86+* Generally speaking, just cleaning things up is not a sufficient reason
87+ to make changes to the stable branch. It has to actually fix a bug.
88+
89+* Changes to the stable branch should include tests as usual.
90+
91+* Don't change or remove existing APIs that might be used by plugins, even
92+ if they are underscore-prefixed. Adding APIs that are also being added
93+ to the trunk branch may make sense.
94+
95+* Keeping consistency with trunk is useful, but less important than
96+ keeping the stable branch stable.
97
98 * (more items welcome)
99
100 References
101 **********
102
103-#. List thread "[rfc] six-month stable release cycles", July 2009.
104+#. List thread "`[rfc] six-month stable release cycles`__", July 2009.
105+
106+.. __: https://lists.ubuntu.com/archives/bazaar/2009q3/060882.html
107
108 ..
109 vim: filetype=rst textwidth=74 ai shiftwidth=4
110
111=== modified file 'doc/en/_templates/index.html'
112--- doc/en/_templates/index.html 2010-01-04 08:11:08 +0000
113+++ doc/en/_templates/index.html 2010-01-08 00:46:12 +0000
114@@ -42,7 +42,7 @@
115 <p class="biglink"><a class="biglink" href="http://bazaar-vcs.org/BzrGlossary/">Glossary</a><br/>
116 <span class="linkdescr">help with terminology</span>
117 </p>
118- <p class="biglink"><a class="biglink" "http://doc.bazaar.canonical.com/developers/">Developer Docs</a><br/>
119+ <p class="biglink"><a class="biglink" href="../developers/">Developer Docs</a><br/>
120 <span class="linkdescr">improving and extending bzr</span>
121 </p>
122 </td>