2 Conventions? Are you kidding? OK fine.
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.
10 Any branch with a "tmp/" prefix might be rebased (often), so keep that
11 in mind when using or depending on one.
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
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
26 - Better VFS performance for large repositories (i.e. fuse, ls,
33 - Incremental indexing via inotify.
35 - Smarter (and quieter) handling of cross-filesystem metadata.
39 - Support for alternate remote storage APIs.
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.)
45 More specific ways to help
46 ==========================
48 Testing -- yes please.
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).
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.
63 Individual tests can be run via
69 ./pytest test/int/test_git.py
70 ./pytest test/ext/test-ftp
72 Internal tests that test bup's code directly are located in test/int,
73 and external tests that test bup from the outside, typically by
74 running the executable, are located in test/ext.
76 Currently, all pytests must be located in either test/ext or test/int.
77 Internal test filenames must match test_*.py, and external tests must
78 be located in text/ext and their filenames must match test-* (see
79 test/ext/conftest.py for the handling of the latter). Any paths
80 matching those criteria will be automatically collected by pytest.
82 Some aspects of the environment are automatically restored after each
83 test via fixtures in conftest.py, including the state of the
84 environment variables and the working directory; the latter is reset
85 to the top of the source tree.
90 As mentioned, all patches should be posted to the mailing list for
91 review, and must be "signed off" by the author before official
92 inclusion (see ./SIGNED-OFF-BY). You can create a "signed off" set of
93 patches in ./patches, ready for submission to the list, like this:
95 git format-patch -s -o patches origin/master
97 which will include all of the patches since origin/master on your
98 current branch. Then you can send them to the list like this:
100 git send-email --to bup-list@googlegroups.com --compose patches/*
102 The use of --compose will cause git to ask you to edit a cover letter
103 that will be sent as the first message.
105 It's also possible to handle everything in one step:
107 git send-email -s --to bup-list@googlegroups.com --compose origin/master
109 and you can add --annotate if you'd like to review or edit each patch
112 For single patches, this might be easier:
114 git send-email -s --to bup-list@googlegroups.com --annotate -n1 HEAD
116 which will send the top patch on the current branch, and will stop to
117 allow you to add comments. You can add comments to the section with
118 the diffstat without affecting the commit message.
120 Of course, unless your machine is set up to handle outgoing mail
121 locally, you may need to configure git to be able to send mail. See
122 git-send-email(1) for further details.
124 Oh, and we do have a ./CODINGSTYLE, hobgoblins and all, though don't
125 let that scare you off. We're not all that fierce.
131 It's not like we have a lot of hard and fast rules, but some of the
132 ideas here aren't altogether terrible:
134 http://www.kernel.org/doc/Documentation/SubmittingPatches
136 In particular, we've been paying at least some attention to the bits
137 regarding Acked-by:, Reported-by:, Tested-by: and Reviewed-by:.