← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Martin Pool
  • Date: 2005-11-28 08:03:42 UTC
  • mto: (1185.33.61 bzr.dev)
  • mto: This revision was merged to the branch mainline in revision 1518.
  • Revision ID: mbp@sourcefrog.net-20051128080342-b7db3190dca90484
[broken] start converting basic_io to more rfc822-like format

Suggestions from mailing list:
 
  no double quotes
  no cute right-alignment
  no escaping
  just indent continuation lines

Show diffs side-by-side

added added

removed removed

Lines of Context:
HACKING
247
247
    Revision 0 is always the null revision; others are 1-based
248
248
    indexes into the branch's revision history.
249
249
 
250
 
 
251
 
Merge/review process
252
 
====================
253
 
 
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
260
 
a branch.
261
 
 
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.
265
 
 
266
 
Anyone is welcome to review code.  There are broadly three gates for
267
 
code to get in:
268
 
 
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
273
 
   and ask for help.
274
 
 
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.
278
 
 
279
 
 * Improves bugs, features, speed, or code simplicity.
280
 
 
281
 
Code that goes in should pass all three.
282
 
 
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.)
287
 
 
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.)
292
 
 
293
 
 
294
 
:: vim:tw=74:ai
 
250
:: vim: tw=74 ai