46
40
If nothing else, perhaps you'll find inspiration in how other developers
47
41
have solved their challenges.
43
Finding Something To Do
44
=======================
46
Ad-hoc performance work can also be done. One useful tool is the 'evil' debug
47
flag. For instance running ``bzr -Devil commit -m "test"`` will log a backtrace
48
to the bzr log file for every method call which triggers a slow or non-scalable
49
part of the bzr library. So checking that a given command with ``-Devil`` has
50
no backtraces logged to the log file is a good way to find problem function
51
calls that might be nested deep in the code base.
50
53
Planning and Discussing Changes
51
54
===============================
73
76
Bazaar Development in a Nutshell
74
77
================================
76
Looking for a 10 minute introduction to submitting a change?
77
See http://bazaar-vcs.org/BzrGivingBack.
79
TODO: Merge that Wiki page into this document.
79
.. was from bazaar-vcs.org/BzrGivingBack
81
One of the fun things about working on a version control system like Bazaar is
82
that the users have a high level of proficiency in contributing back into
83
the tool. Consider the following very brief introduction to contributing back
84
to Bazaar. More detailed instructions are in the following sections.
89
First, get a local copy of the development mainline (See `Why make a local
95
$ bzr branch http://bazaar-vcs.org/bzr/bzr.dev/ bzr.dev
97
Now make your own branch::
99
$ bzr branch bzr.dev 123456-my-bugfix
101
This will give you a branch called "123456-my-bugfix" that you can work on
102
and commit in. Here, you can study the code, make a fix or a new feature.
103
Feel free to commit early and often (after all, it's your branch!).
105
Documentation improvements are an easy place to get started giving back to the
106
Bazaar project. The documentation is in the `doc/` subdirectory of the Bazaar
109
When you are done, make sure that you commit your last set of changes as well!
110
Once you are happy with your changes, ask for them to be merged, as described
113
Making a Merge Proposal
114
-----------------------
116
The Bazaar developers use Launchpad to further enable a truly distributed
117
style of development. Anyone can propose a branch for merging into the Bazaar
118
trunk. To start this process, you need to push your branch to Launchpad. To
119
do this, you will need a Launchpad account and user name, e.g.
120
`your_lp_username`. You can push your branch to Launchpad directly from
123
$ bzr push lp:~your_lp_username/bzr/giveback
125
After you have pushed your branch, you will need to propose it for merging to
126
the Bazaar trunk. Go to <https://launchpad.net/your_lp_username/bzr/giveback>
127
and choose "Propose for merging into another branch". Select "~bzr/bzr/trunk"
128
to hand your changes off to the Bazaar developers for review and merging.
130
Why make a local copy of bzr.dev?
131
---------------------------------
133
Making a local mirror of bzr.dev is not strictly necessary, but it means
135
- You can use that copy of bzr.dev as your main bzr executable, and keep it
136
up-to-date using ``bzr pull``.
137
- Certain operations are faster, and can be done when offline. For example:
140
- ``bzr diff -r ancestor:...``
143
- When it's time to create your next branch, it's more convenient. When you
144
have further contributions to make, you should do them in their own branch::
147
$ bzr branch bzr.dev additional_fixes
148
$ cd additional_fixes # hack, hack, hack
82
152
Understanding the Development Process
204
275
Good reviews do take time. They also regularly require a solid
205
276
understanding of the overall code base. In practice, this means a small
206
277
number of people often have a large review burden - with knowledge comes
207
responsibility. No one like their merge requests sitting in a queue going
278
responsibility. No one likes their merge requests sitting in a queue going
208
279
nowhere, so reviewing sooner rather than later is strongly encouraged.
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
285
Review cover letters
332
374
* (your ideas here...)
335
Bundle Buggy and review outcomes
336
================================
380
From May 2009 on, we prefer people to propose code reviews through
383
* <https://launchpad.net/+tour/code-review>
385
* <https://help.launchpad.net/Code/Review>
387
Anyone can propose or comment on a merge proposal just by creating a
390
There are two ways to create a new merge proposal: through the web
391
interface or by email.
394
Proposing a merge through the web
395
---------------------------------
397
To create the proposal through the web, first push your branch to Launchpad.
398
For example, a branch dealing with documentation belonging to the Launchpad
399
User mbp could be pushed as ::
401
bzr push lp:~mbp/bzr/doc
403
Then go to the branch's web page, which in this case would be
404
<https://code.launchpad.net/~mbp/bzr/doc>. You can simplify this step by just
409
You can then click "Propose for merging into another branch", and enter your
410
cover letter (see above) into the web form. Typically you'll want to merge
411
into ``~bzr/bzr/trunk`` which will be the default; you might also want to
412
nominate merging into a release branch for a bug fix. There is the option to
413
specify a specific reviewer or type of review, and you shouldn't normally
416
Submitting the form takes you to the new page about the merge proposal
417
containing the diff of the changes, comments by interested people, and
418
controls to comment or vote on the change.
420
Proposing a merge by mail
421
-------------------------
423
To propose a merge by mail, send a bundle to ``merge@code.launchpad.net``.
425
You can generate a merge request like this::
427
bzr send -o bug-1234.diff
429
``bzr send`` can also send mail directly if you prefer; see the help.
434
From <https://code.launchpad.net/bzr/+activereviews> you can see all
435
currently active reviews, and choose one to comment on. This page also
436
shows proposals that are now approved and should be merged by someone with
440
Reviews through Bundle Buggy
441
============================
443
The Bundle Buggy tool used up to May 2009 is still available as a review
446
Sending patches for review
447
--------------------------
449
If you'd like to propose a change, please post to the
450
bazaar@lists.canonical.com list with a bundle, patch, or link to a
451
branch. Put ``[PATCH]`` or ``[MERGE]`` in the subject so Bundle Buggy
452
can pick it out, and explain the change in the email message text.
453
Remember to update the NEWS file as part of your change if it makes any
454
changes visible to users or plugin developers. Please include a diff
455
against mainline if you're giving a link to a branch.
457
You can generate a merge request like this::
459
bzr send -o bug-1234.patch
461
A ``.patch`` extension is recommended instead of .bundle as many mail clients
462
will send the latter as a binary file.
464
``bzr send`` can also send mail directly if you prefer; see the help.
466
Please do **NOT** put [PATCH] or [MERGE] in the subject line if you don't
467
want it to be merged. If you want comments from developers rather than
468
to be merged, you can put ``[RFC]`` in the subject line.
470
If this change addresses a bug, please put the bug number in the subject
471
line too, in the form ``[#1]`` so that Bundle Buggy can recognize it.
473
If the change is intended for a particular release mark that in the
474
subject too, e.g. ``[1.6]``.
338
475
Anyone can "vote" on the mailing list by expressing an opinion. Core
339
476
developers can also vote using Bundle Buggy. Here are the voting codes and
340
477
their explanations.
1093
1232
then bzr will go into pdb post-mortem mode when an unhandled exception
1096
If you send a SIGQUIT signal to bzr, which can be done by pressing
1097
Ctrl-\\ on Unix, bzr will go into the debugger immediately. You can
1098
continue execution by typing ``c``. This can be disabled if necessary
1099
by setting the environment variable ``BZR_SIGQUIT_PDB=0``.
1235
If you send a SIGQUIT or SIGBREAK signal to bzr then it will drop into the
1236
debugger immediately. SIGQUIT can be generated by pressing Ctrl-\\ on
1237
Unix. SIGBREAK is generated with Ctrl-Pause on Windows (some laptops have
1238
this as Fn-Pause). You can continue execution by typing ``c``. This can
1239
be disabled if necessary by setting the environment variable
1240
``BZR_SIGQUIT_PDB=0``.
1160
1301
Attempting to print an unprintable character will cause a UnicodeError.
1161
1302
This is for commands that are intended more as scripting support, rather
1162
1303
than plain user review.
1163
For exampl: ``bzr ls`` is designed to be used with shell scripting. One
1164
use would be ``bzr ls --null --unknows | xargs -0 rm``. If ``bzr``
1304
For example: ``bzr ls`` is designed to be used with shell scripting. One
1305
use would be ``bzr ls --null --unknowns | xargs -0 rm``. If ``bzr``
1165
1306
printed a filename with a '?', the wrong file could be deleted. (At the
1166
1307
very least, the correct file would not be deleted). An error is used to
1167
1308
indicate that the requested action could not be performed.
added
removed
doc/developers/HACKING.txt
