247
247
Revision 0 is always the null revision; others are 1-based
248
248
indexes into the branch's revision history.
254
If you'd like to propose a change, please post to the
255
bazaar-ng@lists.canonical.com list with a patch, bzr changeset, or link to a
256
branch. Please put '[patch]' in the subject so we can pick them out, and
257
include some text explaining the change. Remember to put an update to the NEWS
258
file in your diff, if it makes any changes visible to users or plugin
259
developers. Please include a diff against mainline if you're giving a link to
262
Please indicate if you think the code is ready to merge, or if it's just a
263
draft or for discussion. If you want comments from many developers rather than
264
to be merged, you can put '[rfc]' in the subject lines.
266
Anyone is welcome to review code. There are broadly three gates for
269
* Doesn't reduce test coverage: if it adds new methods or commands,
270
there should be tests for them. There is a good test framework
271
and plenty of examples to crib from, but if you are having trouble
272
working out how to test something feel free to post a draft patch
275
* Doesn't reduce design clarity, such as by entangling objects
276
we're trying to separate. This is mostly something the more
277
experienced reviewers need to help check.
279
* Improves bugs, features, speed, or code simplicity.
281
Code that goes in should pass all three.
283
If you read a patch please reply and say so. We can use a numeric scale
284
of -1, -0, +0, +1, meaning respectively "really don't want it in current
285
form", "somewhat uncomfortable", "ok with me", and "please put it in".
286
Anyone can "vote". (It's not really voting, just a terse expression.)
288
If something gets say two +1 votes from core reviewers, and no
289
vetos, then it's OK to come in. Any of the core developers can bring it
290
into their integration branch, which I'll merge regularly. (If you do
291
so, please reply and say so.)
added
removed
HACKING
