76
73
Bazaar Development in a Nutshell
77
74
================================
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/meaningful_name_here
125
After you have pushed your branch, you will need to propose it for merging to
126
the Bazaar trunk. Go to
127
<https://launchpad.net/your_lp_username/bzr/meaningful_name_here> and choose
128
"Propose for merging into another branch". Select "~bzr/bzr/trunk" to hand
129
your changes off to the Bazaar developers for review and merging.
131
Using a meaningful name for your branch will help you and the reviewer(s)
132
better track the submission. Use a very succint description of your submission
133
and prefix it with bug number if needed (lp:~mbp/bzr/484558-merge-directory
134
for example). Alternatively, you can suffix with the bug number
135
(lp:~jameinel/bzr/export-file-511987).
138
Why make a local copy of bzr.dev?
139
---------------------------------
141
Making a local mirror of bzr.dev is not strictly necessary, but it means
143
- You can use that copy of bzr.dev as your main bzr executable, and keep it
144
up-to-date using ``bzr pull``.
145
- Certain operations are faster, and can be done when offline. For example:
148
- ``bzr diff -r ancestor:...``
151
- When it's time to create your next branch, it's more convenient. When you
152
have further contributions to make, you should do them in their own branch::
155
$ bzr branch bzr.dev additional_fixes
156
$ cd additional_fixes # hack, hack, hack
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.
160
82
Understanding the Development Process
161
83
=====================================
163
The development team follows many practices including:
85
The development team follows many best-practices including:
165
87
* a public roadmap and planning process in which anyone can participate
186
108
For further information, see http://bazaar-vcs.org/BzrDevelopment.
111
A Closer Look at the Merge & Review Process
112
===========================================
114
If you'd like to propose a change, please post to the
115
bazaar@lists.canonical.com list with a bundle, patch, or link to a
116
branch. Put '[PATCH]' or '[MERGE]' in the subject so Bundle Buggy
117
can pick it out, and explain the change in the email message text.
118
Remember to update the NEWS file as part of your change if it makes any
119
changes visible to users or plugin developers. Please include a diff
120
against mainline if you're giving a link to a branch.
122
You can generate a bundle like this::
124
bzr bundle > mybundle.patch
126
A .patch extension is recommended instead of .bundle as many mail clients
127
will send the latter as a binary file. If a bundle would be too long or your
128
mailer mangles whitespace (e.g. implicitly converts Unix newlines to DOS
129
newlines), use the merge-directive command instead like this::
131
bzr merge-directive http://bazaar-vcs.org http://example.org/my_branch > my_directive.patch
133
See the help for details on the arguments to merge-directive.
135
Please do **NOT** put [PATCH] or [MERGE] in the subject line if you don't
136
want it to be merged. If you want comments from developers rather than
137
to be merged, you can put '[RFC]' in the subject line.
139
Anyone is welcome to review code. There are broadly three gates for
142
* Doesn't reduce test coverage: if it adds new methods or commands,
143
there should be tests for them. There is a good test framework
144
and plenty of examples to crib from, but if you are having trouble
145
working out how to test something feel free to post a draft patch
148
* Doesn't reduce design clarity, such as by entangling objects
149
we're trying to separate. This is mostly something the more
150
experienced reviewers need to help check.
152
* Improves bugs, features, speed, or code simplicity.
154
Code that goes in should pass all three. The core developers take care
155
to keep the code quality high and understandable while recognising that
156
perfect is sometimes the enemy of good. (It is easy for reviews to make
157
people notice other things which should be fixed but those things should
158
not hold up the original fix being accepted. New things can easily be
159
recorded in the Bug Tracker instead.)
161
Anyone can "vote" on the mailing list. Core developers can also vote using
162
Bundle Buggy. Here are the voting codes and their explanations.
164
:approve: Reviewer wants this submission merged.
165
:tweak: Reviewer wants this submission merged with small changes. (No
167
:abstain: Reviewer does not intend to vote on this patch.
168
:resubmit: Please make changes and resubmit for review.
169
:reject: Reviewer doesn't want this kind of change merged.
170
:comment: Not really a vote. Reviewer just wants to comment, for now.
172
If a change gets two approvals from core reviewers, and no rejections,
173
then it's OK to come in. Any of the core developers can bring it into the
174
bzr.dev trunk and backport it to maintenance branches if required. The
175
Release Manager will merge the change into the branch for a pending
176
release, if any. As a guideline, core developers usually merge their own
177
changes and volunteer to merge other contributions if they were the second
178
reviewer to agree to a change.
180
To track the progress of proposed changes, use Bundle Buggy. See
181
http://bundlebuggy.aaronbentley.com/help for a link to all the
182
outstanding merge requests together with an explanation of the columns.
183
Bundle Buggy will also mail you a link to track just your change.
191
186
Preparing a Sandbox for Making Changes to Bazaar
256
251
Holds documentation on a whole range of things on Bazaar from the
257
252
origination of ideas within the project to information on Bazaar
258
253
features and use cases. Within this directory there is a subdirectory
259
for each translation into a human language. All the documentation
254
for each translation into a human language. All the documentation
260
255
is in the ReStructuredText markup language.
263
Documentation specifically targeted at Bazaar and plugin developers.
258
Documentation specifically targetted at Bazaar and plugin developers.
264
259
(Including this document.)
268
Automatically-generated API reference information is available at
269
<http://starship.python.net/crew/mwh/bzrlibapi/>.
271
See also the `Bazaar Architectural Overview
272
<http://doc.bazaar-vcs.org/developers/overview.html>`_.
275
The Code Review Process
276
#######################
278
All code changes coming in to Bazaar are reviewed by someone else.
279
Normally changes by core contributors are reviewed by one other core
280
developer, and changes from other people are reviewed by two core
281
developers. Use intelligent discretion if the patch is trivial.
283
Good reviews do take time. They also regularly require a solid
284
understanding of the overall code base. In practice, this means a small
285
number of people often have a large review burden - with knowledge comes
286
responsibility. No one likes their merge requests sitting in a queue going
287
nowhere, so reviewing sooner rather than later is strongly encouraged.
296
Please put a "cover letter" on your merge request explaining:
298
* the reason **why** you're making this change
300
* **how** this change achieves this purpose
302
* anything else you may have fixed in passing
304
* anything significant that you thought of doing, such as a more
305
extensive fix or a different approach, but didn't or couldn't do now
307
A good cover letter makes reviewers' lives easier because they can decide
308
from the letter whether they agree with the purpose and approach, and then
309
assess whether the patch actually does what the cover letter says.
310
Explaining any "drive-by fixes" or roads not taken may also avoid queries
311
from the reviewer. All in all this should give faster and better reviews.
312
Sometimes writing the cover letter helps the submitter realize something
313
else they need to do. The size of the cover letter should be proportional
314
to the size and complexity of the patch.
317
Reviewing proposed changes
318
==========================
320
Anyone is welcome to review code, and reply to the thread with their
323
The simplest way to review a proposed change is to just read the patch on
324
the list or in Bundle Buggy. For more complex changes it may be useful
325
to make a new working tree or branch from trunk, and merge the proposed
326
change into it, so you can experiment with the code or look at a wider
329
There are three main requirements for code to get in:
331
* Doesn't reduce test coverage: if it adds new methods or commands,
332
there should be tests for them. There is a good test framework
333
and plenty of examples to crib from, but if you are having trouble
334
working out how to test something feel free to post a draft patch
337
* Doesn't reduce design clarity, such as by entangling objects
338
we're trying to separate. This is mostly something the more
339
experienced reviewers need to help check.
341
* Improves bugs, features, speed, or code simplicity.
343
Code that goes in should not degrade any of these aspects. Patches are
344
welcome that only cleanup the code without changing the external
345
behaviour. The core developers take care to keep the code quality high
346
and understandable while recognising that perfect is sometimes the enemy
349
It is easy for reviews to make people notice other things which should be
350
fixed but those things should not hold up the original fix being accepted.
351
New things can easily be recorded in the Bug Tracker instead.
353
It's normally much easier to review several smaller patches than one large
354
one. You might want to use ``bzr-loom`` to maintain threads of related
355
work, or submit a preparatory patch that will make your "real" change
359
Checklist for reviewers
360
=======================
362
* Do you understand what the code's doing and why?
364
* Will it perform reasonably for large inputs, both in memory size and
365
run time? Are there some scenarios where performance should be
368
* Is it tested, and are the tests at the right level? Are there both
369
blackbox (command-line level) and API-oriented tests?
371
* If this change will be visible to end users or API users, is it
372
appropriately documented in NEWS?
374
* Does it meet the coding standards below?
376
* If it changes the user-visible behaviour, does it update the help
377
strings and user documentation?
379
* If it adds a new major concept or standard practice, does it update the
380
developer documentation?
382
* (your ideas here...)
388
From May 2009 on, we prefer people to propose code reviews through
391
* <https://launchpad.net/+tour/code-review>
393
* <https://help.launchpad.net/Code/Review>
395
Anyone can propose or comment on a merge proposal just by creating a
398
There are two ways to create a new merge proposal: through the web
399
interface or by email.
402
Proposing a merge through the web
403
---------------------------------
405
To create the proposal through the web, first push your branch to Launchpad.
406
For example, a branch dealing with documentation belonging to the Launchpad
407
User mbp could be pushed as ::
409
bzr push lp:~mbp/bzr/doc
411
Then go to the branch's web page, which in this case would be
412
<https://code.launchpad.net/~mbp/bzr/doc>. You can simplify this step by just
417
You can then click "Propose for merging into another branch", and enter your
418
cover letter (see above) into the web form. Typically you'll want to merge
419
into ``~bzr/bzr/trunk`` which will be the default; you might also want to
420
nominate merging into a release branch for a bug fix. There is the option to
421
specify a specific reviewer or type of review, and you shouldn't normally
424
Submitting the form takes you to the new page about the merge proposal
425
containing the diff of the changes, comments by interested people, and
426
controls to comment or vote on the change.
428
Proposing a merge by mail
429
-------------------------
431
To propose a merge by mail, send a bundle to ``merge@code.launchpad.net``.
433
You can generate a merge request like this::
435
bzr send -o bug-1234.diff
437
``bzr send`` can also send mail directly if you prefer; see the help.
263
Automatically-generated API reference information is available at
264
<http://starship.python.net/crew/mwh/bzrlibapi/>.
265
(There is an experimental editable version at
266
<http://starship.python.net/crew/mwh/bzrlibapi-oe/>.)
267
See also the `Essential Domain Classes`_
268
section of this guide.
271
Essential Domain Classes
272
########################
274
Introducing the Object Model
275
============================
277
The core domain objects within the bazaar model are:
287
Transports are explained below. See http://bazaar-vcs.org/Classes/
288
for an introduction to the other key classes.
293
The ``Transport`` layer handles access to local or remote directories.
294
Each Transport object acts like a logical connection to a particular
295
directory, and it allows various operations on files within it. You can
296
*clone* a transport to get a new Transport connected to a subdirectory or
299
Transports are not used for access to the working tree. At present
300
working trees are always local and they are accessed through the regular
301
Python file io mechanisms.
440
304
-----------------
442
From <https://code.launchpad.net/bzr/+activereviews> you can see all
443
currently active reviews, and choose one to comment on. This page also
444
shows proposals that are now approved and should be merged by someone with
448
Reviews through Bundle Buggy
449
============================
451
The Bundle Buggy tool used up to May 2009 is still available as a review
454
Sending patches for review
455
--------------------------
457
If you'd like to propose a change, please post to the
458
bazaar@lists.canonical.com list with a bundle, patch, or link to a
459
branch. Put ``[PATCH]`` or ``[MERGE]`` in the subject so Bundle Buggy
460
can pick it out, and explain the change in the email message text.
461
Remember to update the NEWS file as part of your change if it makes any
462
changes visible to users or plugin developers. Please include a diff
463
against mainline if you're giving a link to a branch.
465
You can generate a merge request like this::
467
bzr send -o bug-1234.patch
469
A ``.patch`` extension is recommended instead of .bundle as many mail clients
470
will send the latter as a binary file.
472
``bzr send`` can also send mail directly if you prefer; see the help.
474
Please do **NOT** put [PATCH] or [MERGE] in the subject line if you don't
475
want it to be merged. If you want comments from developers rather than
476
to be merged, you can put ``[RFC]`` in the subject line.
478
If this change addresses a bug, please put the bug number in the subject
479
line too, in the form ``[#1]`` so that Bundle Buggy can recognize it.
481
If the change is intended for a particular release mark that in the
482
subject too, e.g. ``[1.6]``.
483
Anyone can "vote" on the mailing list by expressing an opinion. Core
484
developers can also vote using Bundle Buggy. Here are the voting codes and
487
:approve: Reviewer wants this submission merged.
488
:tweak: Reviewer wants this submission merged with small changes. (No
490
:abstain: Reviewer does not intend to vote on this patch.
491
:resubmit: Please make changes and resubmit for review.
492
:reject: Reviewer doesn't want this kind of change merged.
493
:comment: Not really a vote. Reviewer just wants to comment, for now.
495
If a change gets two approvals from core reviewers, and no rejections,
496
then it's OK to come in. Any of the core developers can bring it into the
497
bzr.dev trunk and backport it to maintenance branches if required. The
498
Release Manager will merge the change into the branch for a pending
499
release, if any. As a guideline, core developers usually merge their own
500
changes and volunteer to merge other contributions if they were the second
501
reviewer to agree to a change.
503
To track the progress of proposed changes, use Bundle Buggy. See
504
http://bundlebuggy.aaronbentley.com/help for a link to all the
505
outstanding merge requests together with an explanation of the columns.
506
Bundle Buggy will also mail you a link to track just your change.
306
Transports work in URLs. Take note that URLs are by definition only
307
ASCII - the decision of how to encode a Unicode string into a URL must be
308
taken at a higher level, typically in the Store. (Note that Stores also
309
escape filenames which cannot be safely stored on all filesystems, but
310
this is a different level.)
312
The main reason for this is that it's not possible to safely roundtrip a
313
URL into Unicode and then back into the same URL. The URL standard
314
gives a way to represent non-ASCII bytes in ASCII (as %-escapes), but
315
doesn't say how those bytes represent non-ASCII characters. (They're not
316
guaranteed to be UTF-8 -- that is common but doesn't happen everywhere.)
318
For example if the user enters the url ``http://example/%e0`` there's no
319
way to tell whether that character represents "latin small letter a with
320
grave" in iso-8859-1, or "latin small letter r with acute" in iso-8859-2
321
or malformed UTF-8. So we can't convert their URL to Unicode reliably.
323
Equally problematic if we're given a url-like string containing non-ascii
324
characters (such as the accented a) we can't be sure how to convert that
325
to the correct URL, because we don't know what encoding the server expects
326
for those characters. (Although this is not totally reliable we might still
327
accept these and assume they should be put into UTF-8.)
329
A similar edge case is that the url ``http://foo/sweet%2Fsour`` contains
330
one directory component whose name is "sweet/sour". The escaped slash is
331
not a directory separator. If we try to convert URLs to regular Unicode
332
paths this information will be lost.
334
This implies that Transports must natively deal with URLs; for simplicity
335
they *only* deal with URLs and conversion of other strings to URLs is done
336
elsewhere. Information they return, such as from ``list_dir``, is also in
337
the form of URL components.
508
340
Coding Style Guidelines
509
341
#######################
987
795
should be only in the command-line tool.
990
Progress and Activity Indications
991
---------------------------------
993
bzrlib has a way for code to display to the user that stuff is happening
994
during a long operation. There are two particular types: *activity* which
995
means that IO is happening on a Transport, and *progress* which means that
996
higher-level application work is occurring. Both are drawn together by
999
Transport objects are responsible for calling `report_transport_activity`
1002
Progress uses a model/view pattern: application code acts on a
1003
`ProgressTask` object, which notifies the UI when it needs to be
1004
displayed. Progress tasks form a stack. To create a new progress task on
1005
top of the stack, call `bzrlib.ui.ui_factory.nested_progress_bar()`, then
1006
call `update()` on the returned ProgressTask. It can be updated with just
1007
a text description, with a numeric count, or with a numeric count and
1008
expected total count. If an expected total count is provided the view
1009
can show the progress moving along towards the expected total.
1011
The user should call `finish` on the `ProgressTask` when the logical
1012
operation has finished, so it can be removed from the stack.
1014
Progress tasks have a complex relationship with generators: it's a very
1015
good place to use them, but because python2.4 does not allow ``finally``
1016
blocks in generators it's hard to clean them up properly. In this case
1017
it's probably better to have the code calling the generator allocate a
1018
progress task for its use and then call `finalize` when it's done, which
1019
will close it if it was not already closed. The generator should also
1020
finish the progress task when it exits, because it may otherwise be a long
1021
time until the finally block runs.
1027
When filenames or similar variables are presented inline within a message,
1028
they should be enclosed in double quotes (ascii 0x22, not chiral unicode
1031
bzr: ERROR: No such file "asdf"
1033
When we print just a list of filenames there should not be any quoting:
1036
.. _bug 544297: https://bugs.launchpad.net/bugs/544297
1038
https://wiki.ubuntu.com/UnitsPolicy provides a good explanation about
1039
which unit should be used when. Roughly speaking, IEC standard applies
1040
for base-2 units and SI standard applies for base-10 units:
1042
* for network bandwidth and disk sizes, use base-10 (Mbits/s, kB/s, GB)
1044
* for RAM sizes, use base-2 (GiB, TiB)
added
removed
doc/developers/HACKING.txt
