Status: | Merged |
---|---|
Merged at revision: | not available |
Proposed branch: | lp:~lifeless/bzr/docs |
Merge into: | lp:bzr |
Diff against target: | None lines |
To merge this branch: | bzr merge lp:~lifeless/bzr/docs |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Martin Pool | Approve | ||
Review via email: mp+11284@code.launchpad.net |
Commit message
Description of the change
Robert Collins (lifeless) wrote : | # |
Martin Pool (mbp) wrote : | # |
'targeted' has two 't's, not three.
+ updating this if you don't immediately know : its not critical that it be
no space before colons in English.
137 + public_branch = http://
Maybe we should suggest putting it on Launchpad, because then we can also show the use of append_path etc.
Vincent Ladeuil (vila) wrote : | # |
>>>>> "robert" == Robert Collins <email address hidden> writes:
<snip/>
robert> -#. Go to the series web page at <https:/
robert> +#. Go to the series web page at <https:/
I didn't modify that because I wanted them to be working URLs for
the RM. I searched a bit how to use a variable to have a single
place to modify and have them all updated, but ReST is limited in
that regard.
But at least having them pointing at the previous release means
the RM only have to edit the URL while looking at existing
pages...
None of these links do anything harmful without a confirmation (I
checked).
Vincent
Robert Collins (lifeless) wrote : | # |
> >>>>> "robert" == Robert Collins <email address hidden> writes:
>
> <snip/>
>
> robert> -#. Go to the series web page at <https:/
> robert> +#. Go to the series web page at <https:/
>
> I didn't modify that because I wanted them to be working URLs for
> the RM. I searched a bit how to use a variable to have a single
> place to modify and have them all updated, but ReST is limited in
> that regard.
They will have to be updated a lot; surely its easier to just accurately describe how the system works. Otherwise, its unclear /which/ urls should be edited by the RM, and which should be used verbatim.
Remember that we have N concurrent series running now.
Preview Diff
1 | === modified file 'doc/developers/bug-handling.txt' | |||
2 | --- doc/developers/bug-handling.txt 2009-08-24 20:16:15 +0000 | |||
3 | +++ doc/developers/bug-handling.txt 2009-09-07 03:08:30 +0000 | |||
4 | @@ -157,10 +157,17 @@ | |||
5 | 157 | A fix for this bug exists in a branch somewhere. Ideally the bug will | 157 | A fix for this bug exists in a branch somewhere. Ideally the bug will |
6 | 158 | be linked to the branch. | 158 | be linked to the branch. |
7 | 159 | Fix Released | 159 | Fix Released |
12 | 160 | The fix for this bug is now in the bzr trunk. It's not necessarily | 160 | The fix for this bug is now in the bzr branch that this task is for. |
13 | 161 | true that it's released yet, but it will be in the next release. The | 161 | The branch for the default task on a bug is bzr.dev. We use this value |
14 | 162 | bug target milestone should be set to the release it went into, but | 162 | even though the fix may not have been been included in a release yet |
15 | 163 | don't spend too much time updating this if you don't immediately know. | 163 | because all the developer activity around it is complete and we want to |
16 | 164 | both avoid bug spam when releases happen, and keep the list of bugs that | ||
17 | 165 | developers see when they look at the bug tracker trimmed to those that | ||
18 | 166 | require action. When setting a bug task to fix released, the bug target | ||
19 | 167 | milestone should be set to the release the fix will be included in (or | ||
20 | 168 | was included in, if you are updating an old bug). Don't spend too much time | ||
21 | 169 | updating this if you don't immediately know : its not critical that it be | ||
22 | 170 | set. | ||
23 | 164 | 171 | ||
24 | 165 | 172 | ||
25 | 166 | Bug Importance | 173 | Bug Importance |
26 | @@ -204,16 +211,14 @@ | |||
27 | 204 | *************** | 211 | *************** |
28 | 205 | 212 | ||
29 | 206 | It's possible to target a bug to a milestone, eg | 213 | It's possible to target a bug to a milestone, eg |
33 | 207 | <https://bugs.edge.launchpad.net/bzr/+milestone/1.16>. We use this mostly | 214 | <https://bugs.edge.launchpad.net/bzr/+milestone/1.16>. We use this to help the |
34 | 208 | to help the release manager know what **must** be merged to make the | 215 | release manager know what **must** be merged to make the release. |
32 | 209 | release. | ||
35 | 210 | 216 | ||
36 | 211 | Therefore, we don't target bugs that we'd like to have fixed or that could | 217 | Therefore, we don't target bugs that we'd like to have fixed or that could |
37 | 212 | be fixed in a particular release, we only target bugs that must be fixed | 218 | be fixed in a particular release, we only target bugs that must be fixed |
42 | 213 | and that will or might cause us to decide to slip the release if they're | 219 | and that will cause us to slip the release if they're not fixed. At any time, |
43 | 214 | not fixed. At any time, very few if any of the bugs targetted to a | 220 | very few if any of the bugs targetted to a release should be still open. By |
44 | 215 | release should be still open. By definition, these bugs should normally | 221 | definition, these bugs should normally be Critical priority. |
41 | 216 | be Critical priority. | ||
45 | 217 | 222 | ||
46 | 218 | 223 | ||
47 | 219 | Backports | 224 | Backports |
48 | @@ -224,8 +229,10 @@ | |||
49 | 224 | represent this, create a new bug task (ie link in the status table on the | 229 | represent this, create a new bug task (ie link in the status table on the |
50 | 225 | bug page) by clicking the `poorly-named | 230 | bug page) by clicking the `poorly-named |
51 | 226 | <https://bugs.launchpad.net/bugs/132733>`_ "Target to Release" link. | 231 | <https://bugs.launchpad.net/bugs/132733>`_ "Target to Release" link. |
54 | 227 | Target it to the appropriate series (ie 1.15) and then to the milestone | 232 | Target it to the appropriate series (ie 1.15). If the bug should also |
55 | 228 | within that release. | 233 | prevent any point releases of that series then you should also target the |
56 | 234 | new task to the appropriate milestone within that release. (See Targeting Bugs | ||
57 | 235 | above) | ||
58 | 229 | 236 | ||
59 | 230 | This bug task then has a separate status and importance to indicate the | 237 | This bug task then has a separate status and importance to indicate the |
60 | 231 | separate work to get it into that release. | 238 | separate work to get it into that release. |
61 | 232 | 239 | ||
62 | === modified file 'doc/developers/integration.txt' | |||
63 | --- doc/developers/integration.txt 2008-04-08 10:55:41 +0000 | |||
64 | +++ doc/developers/integration.txt 2009-09-07 03:16:28 +0000 | |||
65 | @@ -197,7 +197,7 @@ | |||
66 | 197 | 197 | ||
67 | 198 | from bzrlib import branch | 198 | from bzrlib import branch |
68 | 199 | 199 | ||
70 | 200 | b = branch.Branch.open('http://bazaar-vcs.org/bzr/bzr.dev') | 200 | b = branch.Branch.open('http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev') |
71 | 201 | nb = b.bzrdir.sprout('/tmp/newBzrBranch').open_branch() | 201 | nb = b.bzrdir.sprout('/tmp/newBzrBranch').open_branch() |
72 | 202 | 202 | ||
73 | 203 | 203 | ||
74 | @@ -213,7 +213,7 @@ | |||
75 | 213 | from bzrlib import branch | 213 | from bzrlib import branch |
76 | 214 | 214 | ||
77 | 215 | b1 = branch.Branch.open('file:///home/user/mybranch') | 215 | b1 = branch.Branch.open('file:///home/user/mybranch') |
79 | 216 | b2 = branch.Branch.open('http://bazaar-vcs.org/bzr/bzr.dev') | 216 | b2 = branch.Branch.open('http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev') |
80 | 217 | b1.push(b2) | 217 | b1.push(b2) |
81 | 218 | 218 | ||
82 | 219 | 219 | ||
83 | 220 | 220 | ||
84 | === modified file 'doc/developers/releasing.txt' | |||
85 | --- doc/developers/releasing.txt 2009-08-30 21:34:42 +0000 | |||
86 | +++ doc/developers/releasing.txt 2009-09-07 03:16:28 +0000 | |||
87 | @@ -26,10 +26,10 @@ | |||
88 | 26 | #. Create a new series at <https://launchpad.net/bzr/+addseries>. There is one | 26 | #. Create a new series at <https://launchpad.net/bzr/+addseries>. There is one |
89 | 27 | series for every *x.y* release. | 27 | series for every *x.y* release. |
90 | 28 | 28 | ||
92 | 29 | #. Go to the series web page at <https://launchpad.net/bzr/2.0> | 29 | #. Go to the series web page at <https://launchpad.net/bzr/x.y> |
93 | 30 | 30 | ||
94 | 31 | #. Create a new release at | 31 | #. Create a new release at |
96 | 32 | <https://launchpad.net/bzr/2.0/+addrelease> and add | 32 | <https://launchpad.net/bzr/x.y/+addrelease> and add |
97 | 33 | information about this release. We will not use it yet, but it | 33 | information about this release. We will not use it yet, but it |
98 | 34 | will be available for targeting or nominating bugs. | 34 | will be available for targeting or nominating bugs. |
99 | 35 | 35 | ||
100 | @@ -39,7 +39,7 @@ | |||
101 | 39 | general development continues on the trunk, and only | 39 | general development continues on the trunk, and only |
102 | 40 | specifically-targeted fixes go into the release branch. | 40 | specifically-targeted fixes go into the release branch. |
103 | 41 | 41 | ||
105 | 42 | #. Add milestones at <https://edge.launchpad.net/bzr/2.0/+addmilestone> to | 42 | #. Add milestones at <https://edge.launchpad.net/bzr/x.y/+addmilestone> to |
106 | 43 | that series for the beta release, release candidate and the final release, | 43 | that series for the beta release, release candidate and the final release, |
107 | 44 | and their expected dates. | 44 | and their expected dates. |
108 | 45 | 45 | ||
109 | @@ -58,10 +58,8 @@ | |||
110 | 58 | 58 | ||
111 | 59 | When it's time to make the first beta release or release candidate: | 59 | When it's time to make the first beta release or release candidate: |
112 | 60 | 60 | ||
117 | 61 | #. Create a new milestone at <https://launchpad.net/bzr/2.0/+addmilestone> | 61 | #. Make a beta release or release candidate. The milestone for this |
118 | 62 | for the beta release or release candidate. | 62 | candidate will already exist (see Starting a cycle above). |
115 | 63 | |||
116 | 64 | #. Make a beta release or release candidate. | ||
119 | 65 | 63 | ||
120 | 66 | Preparing the tree for release | 64 | Preparing the tree for release |
121 | 67 | ------------------------------ | 65 | ------------------------------ |
122 | @@ -71,13 +69,14 @@ | |||
123 | 71 | 69 | ||
124 | 72 | bzr branch trunk prepare-1.14 | 70 | bzr branch trunk prepare-1.14 |
125 | 73 | 71 | ||
127 | 74 | #. Configure pqm-submit for this branch, with a section like this in | 72 | #. Configure pqm-submit for this branch, with a section like this (where |
128 | 73 | x.y is the version to release). | ||
129 | 75 | ``~/.bazaar/locations.conf``:: | 74 | ``~/.bazaar/locations.conf``:: |
130 | 76 | 75 | ||
132 | 77 | [/home/mbp/bzr/prepare-1.14] | 76 | [/home/mbp/bzr/prepare-x.y] |
133 | 78 | pqm_email = Canonical PQM <pqm@bazaar-vcs.org> | 77 | pqm_email = Canonical PQM <pqm@bazaar-vcs.org> |
136 | 79 | submit_branch = lp:bzr/2.0 | 78 | submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y |
137 | 80 | public_branch = http://bazaar.example.com/prepare-2.0 | 79 | public_branch = http://bazaar.example.com/prepare-x.y |
138 | 81 | submit_to = bazaar@lists.canonical.com | 80 | submit_to = bazaar@lists.canonical.com |
139 | 82 | smtp_server = mail.example.com:25 | 81 | smtp_server = mail.example.com:25 |
140 | 83 | 82 |
Update docs for milestones to be a little tighter on language, and remove the inconsistency between 'starting a cycle' and 'doing a release'. Also document the right location for trunk in demo code and rm guidelines.