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.32 release, we're working on 0.33, 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   - Discontinuing Python 2 work, excepting perhaps some bugfixes.
  42
  43 If you have the time and inclination, please help review patches
  44 posted to the list, or post your own.  (See "ways to help" below.)
  45
  46
  47 More specific ways to help
  48 ==========================
  49
  50 Testing -- yes please.
  51
  52 With respect to patches, bup development is handled via the mailing
  53 list, and all patches should be sent to the list for review (see
  54 "Submitting Patches" below).
  55
  56 In most cases, we try to wait until we have at least one or two
  57 "Reviewed-by:" replies to a patch posted to the list before
  58 incorporating it into master, so reviews are an important way to help.
  59 We also love a good "Tested-by:" -- the more the merrier.
  60
  61
  62 Testing
  63 =======
  64
  65 Individual tests can be run via
  66
  67     ./pytest TEST
  68
  69 For example:
  70
  71     ./pytest test/int/test_git.py
  72     ./pytest test/ext/test-ftp
  73
  74 If you have the xdist module installed, then you can specify its `-n`
  75 option to run the tests in parallel (e.g. `./pytest -nauto ...`), or
  76 you can specify `-j` to make, which will be translated to xdist with
  77 `-j` becoming `-nauto` and `-jN` becoming `-nN`.
  78
  79 Internal tests that test bup's code directly are located in test/int,
  80 and external tests that test bup from the outside, typically by
  81 running the executable, are located in test/ext.
  82
  83 Currently, all pytests must be located in either test/ext or test/int.
  84 Internal test filenames must match test_*.py, and external tests must
  85 be located in text/ext and their filenames must match test-* (see
  86 test/ext/conftest.py for the handling of the latter).  Any paths
  87 matching those criteria will be automatically collected by pytest.
  88
  89 Some aspects of the environment are automatically restored after each
  90 test via fixtures in conftest.py, including the state of the
  91 environment variables and the working directory; the latter is reset
  92 to the top of the source tree.
  93
  94 Submitting patches
  95 ==================
  96
  97 As mentioned, all patches should be posted to the mailing list for
  98 review, and must be "signed off" by the author before official
  99 inclusion (see ./SIGNED-OFF-BY).  You can create a "signed off" set of
 100 patches in ./patches, ready for submission to the list, like this:
 101
 102     git format-patch -s -o patches origin/master
 103
 104 which will include all of the patches since origin/master on your
 105 current branch.  Then you can send them to the list like this:
 106
 107     git send-email --to bup-list@googlegroups.com --compose patches/*
 108
 109 The use of --compose will cause git to ask you to edit a cover letter
 110 that will be sent as the first message.
 111
 112 It's also possible to handle everything in one step:
 113
 114     git send-email -s --to bup-list@googlegroups.com --compose origin/master
 115
 116 and you can add --annotate if you'd like to review or edit each patch
 117 before it's sent.
 118
 119 For single patches, this might be easier:
 120
 121     git send-email -s --to bup-list@googlegroups.com --annotate -n1 HEAD
 122
 123 which will send the top patch on the current branch, and will stop to
 124 allow you to add comments.  You can add comments to the section with
 125 the diffstat without affecting the commit message.
 126
 127 Of course, unless your machine is set up to handle outgoing mail
 128 locally, you may need to configure git to be able to send mail.  See
 129 git-send-email(1) for further details.
 130
 131 Oh, and we do have a ./CODINGSTYLE, hobgoblins and all, though don't
 132 let that scare you off.  We're not all that fierce.
 133
 134
 135 Even More Generally
 136 ===================
 137
 138 It's not like we have a lot of hard and fast rules, but some of the
 139 ideas here aren't altogether terrible:
 140
 141   http://www.kernel.org/doc/Documentation/SubmittingPatches
 142
 143 In particular, we've been paying at least some attention to the bits
 144 regarding Acked-by:, Reported-by:, Tested-by: and Reviewed-by:.
 145
 146 <!--
 147 Local Variables:
 148 mode: markdown
 149 End:
 150 -->