HACKING

   1
   2 Conventions?  Are you kidding?  OK fine.
   3
   4 Code Branching Model
   5 ====================
   6
   7 The master branch is what we consider the main-line of development,
   8 and the last, non-rc tag on master is the most recent stable release.
   9
  10 Any branch with a "tmp/" prefix might be rebased (often), so keep that
  11 in mind when using or depending on one.
  12
  13 Any branch with a "tmp/review/" prefix corresponds to a patchset
  14 submitted to the mailing list.  We try to maintain these branches to
  15 make the review process easier for those not as familiar with patches
  16 via email.
  17
  18
  19 Current Trajectory
  20 ==================
  21
  22 Now that we've finished the 0.31 release, we're working on 0.32, and
  23 although we're not certain which new features will be included, we're
  24 considering:
  25
  26   - Better VFS performance for large repositories (i.e. fuse, ls,
  27     web...).
  28
  29   - Better VFS caching.
  30
  31   - Index improvements.
  32
  33   - Incremental indexing via inotify.
  34
  35   - Smarter (and quieter) handling of cross-filesystem metadata.
  36
  37   - Encryption.
  38
  39   - Support for alternate remote storage APIs.
  40
  41 If you have the time and inclination, please help review patches
  42 posted to the list, or post your own.  (See "ways to help" below.)
  43
  44
  45 More specific ways to help
  46 ==========================
  47
  48 Testing -- yes please.
  49
  50 With respect to patches, bup development is handled via the mailing
  51 list, and all patches should be sent to the list for review (see
  52 "Submitting Patches" below).
  53
  54 In most cases, we try to wait until we have at least one or two
  55 "Reviewed-by:" replies to a patch posted to the list before
  56 incorporating it into master, so reviews are an important way to help.
  57 We also love a good "Tested-by:" -- the more the merrier.
  58
  59
  60 Testing
  61 =======
  62
  63 You can run the test suite much more quickly via "make -j test" (as
  64 compared to "make test"), at the expense of slightly more confusing
  65 output (interleaved parallel test output), and inaccurate intermediate
  66 success/failure counts, but the final counts displayed should be
  67 correct.
  68
  69 Individual non-Python tests can be run via "./wvtest run test/TEST" and
  70 if you'd like to see all of the test output, you can omit the wvtest
  71 run wrapper: "test/TEST"
  72
  73 Individual Python tests can be run via "./wvtest run ./wvtest.py
  74 test/int/TEST", and as above, you can see all the output by omitting
  75 the wvtest run wrapper like this: "./wvtest.py test/TEST"
  76
  77 Internal tests that test bup's code directly are located in test/int,
  78 and external tests that test bup from the outside, typically by
  79 running the executable, are located in test/ext.
  80
  81
  82 Submitting patches
  83 ==================
  84
  85 As mentioned, all patches should be posted to the mailing list for
  86 review, and must be "signed off" by the author before official
  87 inclusion (see ./SIGNED-OFF-BY).  You can create a "signed off" set of
  88 patches in ./patches, ready for submission to the list, like this:
  89
  90     git format-patch -s -o patches origin/master
  91
  92 which will include all of the patches since origin/master on your
  93 current branch.  Then you can send them to the list like this:
  94
  95     git send-email --to bup-list@googlegroups.com --compose patches/*
  96
  97 The use of --compose will cause git to ask you to edit a cover letter
  98 that will be sent as the first message.
  99
 100 It's also possible to handle everything in one step:
 101
 102     git send-email -s --to bup-list@googlegroups.com --compose origin/master
 103
 104 and you can add --annotate if you'd like to review or edit each patch
 105 before it's sent.
 106
 107 For single patches, this might be easier:
 108
 109     git send-email -s --to bup-list@googlegroups.com --annotate -n1 HEAD
 110
 111 which will send the top patch on the current branch, and will stop to
 112 allow you to add comments.  You can add comments to the section with
 113 the diffstat without affecting the commit message.
 114
 115 Of course, unless your machine is set up to handle outgoing mail
 116 locally, you may need to configure git to be able to send mail.  See
 117 git-send-email(1) for further details.
 118
 119 Oh, and we do have a ./CODINGSTYLE, hobgoblins and all, though don't
 120 let that scare you off.  We're not all that fierce.
 121
 122
 123 Even More Generally
 124 ===================
 125
 126 It's not like we have a lot of hard and fast rules, but some of the
 127 ideas here aren't altogether terrible:
 128
 129   http://www.kernel.org/doc/Documentation/SubmittingPatches
 130
 131 In particular, we've been paying at least some attention to the bits
 132 regarding Acked-by:, Reported-by:, Tested-by: and Reviewed-by:.