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.25 release, we're working on 0.26, and
  23 although we're not certain which new features will eventually be
  24 included, here are some possible candidates:
  25
  26   - Support for rm/gc.
  27   - Support for remote (push and/or pull) restore.
  28   - Support for some kind of push/pull.
  29   - Smarter (and quieter) handling of cross-filesystem metadata.
  30
  31 If you have the time and inclination, please help review patches
  32 posted to the list, or post your own.  (See "ways to help" below.)
  33
  34
  35 More specific ways to help
  36 ==========================
  37
  38 Testing -- yes please.
  39
  40 With respect to patches, bup development is handled via the mailing
  41 list, and all patches should be sent to the list for review (see
  42 "Submitting Patches" below).
  43
  44 In most cases, we try to wait until we have at least one or two
  45 "Reviewed-by:" replies to a patch posted to the list before
  46 incorporating it into master, so reviews are an important way to help.
  47 We also love a good "Tested-by:" -- the more the merrier.
  48
  49
  50 Submitting patches
  51 ==================
  52
  53 As mentioned, all patches should be posted to the mailing list for
  54 review, and must be "signed off" by the author before official
  55 inclusion (see ./SIGNED-OFF-BY).  You can create a "signed off" set of
  56 patches in ./pending, ready for submission to the list, like this:
  57
  58     git format-patch -s -o patches origin/master
  59
  60 which will include all of the patches since origin/master on your
  61 current branch.  Then you can send them to the list like this:
  62
  63     git send-email --to bup-list@googlegroups.com --compose patches/*
  64
  65 The use of --compose will cause git to ask you to edit a cover letter
  66 that will be sent as the first message.
  67
  68 It's also possible to handle everything in one step:
  69
  70     git send-email -s --to bup-list@googlegroups.com --compose origin/master
  71
  72 and you can add --annotate if you'd like to review or edit each patch
  73 before it's sent.
  74
  75 For single patches, this might be easier:
  76
  77     git send-email -s --to bup-list@googlegroups.com --annotate -n1 HEAD
  78
  79 which will send the top patch on the current branch, and will stop to
  80 allow you to add comments.  You can add comments to the section with
  81 the diffstat without affecting the commit message.
  82
  83 Of course, unless your machine is set up to handle outgoing mail
  84 locally, you may need to configure git to be able to send mail.  See
  85 git-send-email(1) for further details.
  86
  87 Oh, and we do have a ./CODING-STYLE, hobgoblins and all, though don't
  88 let that scare you off.  We're not all that fierce.
  89
  90
  91 Even More Generally
  92 ===================
  93
  94 It's not like we have a lot of hard and fast rules, but some of the
  95 ideas here aren't altogether terrible:
  96
  97   http://www.kernel.org/doc/Documentation/SubmittingPatches
  98
  99 In particular, we've been paying at least some attention to the bits
 100 regarding Acked-by:, Reported-by:, Tested-by: and Reviewed-by:.