← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Ian Clatworthy
  • Date: 2007-05-02 04:43:27 UTC
  • mto: (2475.2.3 doc)
  • mto: This revision was merged to the branch mainline in revision 2477.
  • Revision ID: ian.clatworthy@internode.on.net-20070502044327-uvny1xwti20eh1p3
Incorporate feedback from Aaron B. & Alex B.

Show diffs side-by-side

added added

removed removed

Lines of Context:
HACKING
24
24
 
25
25
* The Plugins page on the Wiki - http://bazaar-vcs.org/BzrPlugins
26
26
 
27
 
* The Bazaar product family on Launchpad -https://launchpad.net/bazaar
 
27
* The Bazaar product family on Launchpad - https://launchpad.net/bazaar
28
28
 
29
29
* Bug Tracker for the core product - https://bugs.launchpad.net/bzr/
30
30
 
99
99
===========================================
100
100
 
101
101
If you'd like to propose a change, please post to the
102
 
bazaar@lists.canonical.com list with a patch, bzr changeset, or link to a
103
 
branch.  Please put '[patch]' in the subject so we can pick them out, and
104
 
include some text explaining the change.  Remember to put an update to the NEWS
105
 
file in your diff, if it makes any changes visible to users or plugin
106
 
developers.  Please include a diff against mainline if you're giving a link to
107
 
a branch.
108
 
 
109
 
Please indicate if you think the code is ready to merge, or if it's just a
110
 
draft or for discussion.  If you want comments from many developers rather than
111
 
to be merged, you can put '[rfc]' in the subject lines.
 
102
bazaar@lists.canonical.com list with a bundle, patch, or link to a
 
103
branch. Put '[PATCH]' or '[MERGE]' in the subject so Bundle Buggy
 
104
can pick it out, and explain the change in the email message text.
 
105
Remember to update the NEWS file as part of your change if it makes any
 
106
changes visible to users or plugin developers. Please include a diff
 
107
against mainline if you're giving a link to a branch.
 
108
 
 
109
You can generate a bundle like this:
 
110
 
 
111
  bzr bundle > mybundle.patch
 
112
  
 
113
A .patch extension is recommended instead of .bundle as many mail clients
 
114
will send the latter as a binary file. If a bundle would be too long or your
 
115
mailer mangles whitespace (e.g. implicitly converts Unix newlines to DOS
 
116
newlines), use the merge-directive command instead like this:
 
117
 
 
118
  bzr merge-directive http://bazaar-vcs.org http://example.org/my_branch > my_directive.patch
 
119
 
 
120
See the help for details on the arguments to merge-directive.
 
121
 
 
122
Please do **NOT** put [PATCH] or [MERGE] in the subject line if you don't
 
123
want it to be merged. If you want comments from developers rather than
 
124
to be merged, you can put '[RFC]' in the subject line.
112
125
 
113
126
Anyone is welcome to review code.  There are broadly three gates for
114
127
code to get in:
125
138
 
126
139
 * Improves bugs, features, speed, or code simplicity.
127
140
 
128
 
Code that goes in should pass all three.
129
 
 
130
 
If you read a patch please reply and say so.  We can use a numeric scale
131
 
of -1, -0, +0, +1, meaning respectively "really don't want it in current
132
 
form", "somewhat uncomfortable", "ok with me", and "please put it in".
133
 
Anyone can "vote".   (It's not really voting, just a terse expression.)
134
 
 
135
 
If something gets say two +1 votes from core reviewers, and no
 
141
Code that goes in should pass all three. The core developers take care
 
142
to keep the code quality high and understandable while recognising that
 
143
perfect is sometimes the enemy of good. (It is easy for reviews to make
 
144
people notice other things which should be fixed but those things should
 
145
not hold up the original fix being accepted. New things can easily be
 
146
recorded in the Bug Tracker instead.)
 
147
 
 
148
Anyone can "vote" on the mailing list. Core developers can also vote using
 
149
Bundle Buggy. Here are the voting codes and their explanations.
 
150
 
 
151
  -1    really don't want it in current form
 
152
  -0    somewhat uncomfortable 
 
153
  +0    comfortable but resubmission after changes requested
 
154
  +1 conditional        good to go after some minor changes
 
155
  +1    good to go
 
156
 
 
157
+1 conditional is used as a way to avoid another submit/review cycle for
 
158
patches that need small changes.
 
159
 
 
160
If a change gets two +1 votes from core reviewers, and no
136
161
vetos, then it's OK to come in.  Any of the core developers can bring it
137
 
into their integration branch, which I'll merge regularly.  (If you do
138
 
so, please reply and say so.)
 
162
into the bzr.dev trunk and backport it to maintenance branches if required.
 
163
The Release Manager will merge the change into the branch for a pending
 
164
release, if any. As a guideline, core developers usually merge their own
 
165
changes and volunteer to merge other contributions if they were the second
 
166
reviewer to agree to a change.
 
167
 
 
168
To track the progress of proposed changes, use Bundle Buggy. See
 
169
http://bundlebuggy.aaronbentley.com/help for a link to all the
 
170
outstanding merge requests together with an explanation of the columns.
 
171
Bundle Buggy will also mail you a link to track just your change.
139
172
 
140
173
 
141
174
Preparing a Sandbox for Making Changes to Bazaar
176
209
http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.html.
177
210
 
178
211
 
179
 
Test Driven Development for Bazaar
180
 
##################################
 
212
Testing Bazaar
 
213
##############
181
214
 
182
 
Why TDD?
183
 
========
 
215
The Importance of Testing
 
216
=========================
184
217
 
185
218
Reliability is a critical success factor for any Version Control System.
186
219
We want Bazaar to be highly reliable across multiple platforms while
785
818
then bzr will go into pdb post-mortem mode when an unhandled exception
786
819
occurs.
787
820
 
788
 
If you send a SIGQUIT signal to bzr, which can be done by pressing C-\ on Unix,
789
 
bzr will go into the debugger immediately.  You can continue execution by
790
 
typing ``c``.  This can be disabled if necessary by setting the
791
 
environment variable ``BZR_SIGQUIT_PDB=0``.
 
821
If you send a SIGQUIT signal to bzr, which can be done by pressing
 
822
Ctrl-\\ on Unix, bzr will go into the debugger immediately.  You can
 
823
continue execution by typing ``c``.  This can be disabled if necessary
 
824
by setting the environment variable ``BZR_SIGQUIT_PDB=0``.
792
825
 
793
826
 
794
827
Jargon