212
Sending patches for review
213
==========================
215
If you'd like to propose a change, please post to the
216
bazaar@lists.canonical.com list with a bundle, patch, or link to a
217
branch. Put ``[PATCH]`` or ``[MERGE]`` in the subject so Bundle Buggy
218
can pick it out, and explain the change in the email message text.
219
Remember to update the NEWS file as part of your change if it makes any
220
changes visible to users or plugin developers. Please include a diff
221
against mainline if you're giving a link to a branch.
223
You can generate a merge request like this::
225
bzr send -o bug-1234.patch
227
A ``.patch`` extension is recommended instead of .bundle as many mail clients
228
will send the latter as a binary file.
230
``bzr send`` can also send mail directly if you prefer; see the help.
232
Please do **NOT** put [PATCH] or [MERGE] in the subject line if you don't
233
want it to be merged. If you want comments from developers rather than
234
to be merged, you can put ``[RFC]`` in the subject line.
236
If this change addresses a bug, please put the bug number in the subject
237
line too, in the form ``[#1]`` so that Bundle Buggy can recognize it.
239
If the change is intended for a particular release mark that in the
240
subject too, e.g. ``[1.6]``.
243
214
Review cover letters
332
303
* (your ideas here...)
335
Bundle Buggy and review outcomes
336
================================
309
From May 2009 on, we prefer people to propose code reviews through
312
* <https://launchpad.net/+tour/code-review>
314
* <https://help.launchpad.net/Code/Review>
316
Anyone can propose or comment on a merge propsal just by creating a
319
There are two ways to create a new merge proposal: through the web
320
interface or by email.
323
Proposing a merge through the web
324
---------------------------------
326
To create the propsal through the web: push your branch to Launchpad, eg::
328
bzr push lp:~mbp/bzr/doc
330
then go to the branch's web page, which in this case would be
331
<https://code.launchpad.net/~mbp/bzr/doc>. You can automate that by just
336
You can then click "Propose for merging into another branch", and enter a
337
cover letter into the web form. Typically you'll want to merge into
338
``~bzr/bzr/trunk`` which will be the default; you might also want to
339
nominate merging into a release branch for a bug fix. There is the option
340
to specify a specific reviewer or type of review, and you shouldn't
341
normally change those.
343
Submitting the form takes you to the new page about the merge proposal
344
containing the diff of the changes, comments by interested people, and
345
controls to comment or vote on the change.
347
Proposing a merge by mail
348
-------------------------
350
To propose a merge by mail, send a bundle to ``merge@code.launchpad.net``.
352
You can generate a merge request like this::
354
bzr send -o bug-1234.diff
356
``bzr send`` can also send mail directly if you prefer; see the help.
361
From <https://code.launchpad.net/bzr/+activereviews> you can see all
362
currently active reviews, and choose one to comment on. This page also
363
shows proposals that are now approved and should be merged by someone with
367
Reviews through Bundle Buggy
368
============================
370
The Bundle Buggy tool used up to May 2009 is still available as a review
373
Sending patches for review
374
--------------------------
376
If you'd like to propose a change, please post to the
377
bazaar@lists.canonical.com list with a bundle, patch, or link to a
378
branch. Put ``[PATCH]`` or ``[MERGE]`` in the subject so Bundle Buggy
379
can pick it out, and explain the change in the email message text.
380
Remember to update the NEWS file as part of your change if it makes any
381
changes visible to users or plugin developers. Please include a diff
382
against mainline if you're giving a link to a branch.
384
You can generate a merge request like this::
386
bzr send -o bug-1234.patch
388
A ``.patch`` extension is recommended instead of .bundle as many mail clients
389
will send the latter as a binary file.
391
``bzr send`` can also send mail directly if you prefer; see the help.
393
Please do **NOT** put [PATCH] or [MERGE] in the subject line if you don't
394
want it to be merged. If you want comments from developers rather than
395
to be merged, you can put ``[RFC]`` in the subject line.
397
If this change addresses a bug, please put the bug number in the subject
398
line too, in the form ``[#1]`` so that Bundle Buggy can recognize it.
400
If the change is intended for a particular release mark that in the
401
subject too, e.g. ``[1.6]``.
338
402
Anyone can "vote" on the mailing list by expressing an opinion. Core
339
403
developers can also vote using Bundle Buggy. Here are the voting codes and
340
404
their explanations.
824
889
should be only in the command-line tool.
892
Progress and Activity Indications
893
---------------------------------
895
bzrlib has a way for code to display to the user that stuff is happening
896
during a long operation. There are two particular types: *activity* which
897
means that IO is happening on a Transport, and *progress* which means that
898
higher-level application work is occurring. Both are drawn together by
901
Transport objects are responsible for calling `report_transport_activity`
904
Progress uses a model/view pattern: application code acts on a
905
`ProgressTask` object, which notifies the UI when it needs to be
906
displayed. Progress tasks form a stack. To create a new progress task on
907
top of the stack, call `bzrlib.ui.ui_factory.nested_progress_bar()`, then
908
call `update()` on the returned ProgressTask. It can be updated with just
909
a text description, with a numeric count, or with a numeric count and
910
expected total count. If an expected total count is provided the view
911
can show the progress moving along towards the expected total.
913
The user should call `finish` on the `ProgressTask` when the logical
914
operation has finished, so it can be removed from the stack.
916
Progress tasks have a complex relatioship with generators: it's a very
917
good place to use them, but because python2.4 does not allow ``finally``
918
blocks in generators it's hard to clean them up properly. In this case
919
it's probably better to have the code calling the generator allocate a
920
progress task for its use and then call `finalize` when it's done, which
921
will close it if it was not already closed. The generator should also
922
finish the progress task when it exits, because it may otherwise be a long
923
time until the finally block runs.
added
removed
doc/en/developer-guide/HACKING.txt
