The master branch is what we consider the main-line of development,
and the last, non-rc tag on master is the most recent stable release.
-Of course, in all fairness, it has been a *long* time since the last
-stable release, but we're working fairly hard to fix that -- no,
-seriously.
-
Any branch with a "tmp/" prefix might be rebased (often), so keep that
in mind when using or depending on one.
+Any branch with a "tmp/review/" prefix corresponds to a patchset
+submitted to the mailing list. We try to maintain these branches to
+make the review process easier for those not as familiar with patches
+via email.
+
Current Trajectory
==================
-At the moment, the primary goal is to test master in preparation for a
-0.25 release, which among many other things will include more complete
-support for filesystem metadata.
+Now that we've finished the 0.31 release, we're working on 0.32, and
+although we're not certain which new features will be included, we're
+considering:
+
+ - Better VFS performance for large repositories (i.e. fuse, ls,
+ web...).
+
+ - Better VFS caching.
+
+ - Index improvements.
+
+ - Incremental indexing via inotify.
+
+ - Smarter (and quieter) handling of cross-filesystem metadata.
+
+ - Encryption.
+
+ - Support for alternate remote storage APIs.
If you have the time and inclination, please help review patches
-posted to the list for inclusion in 0.25. (See below.)
+posted to the list, or post your own. (See "ways to help" below.)
More specific ways to help
list, and all patches should be sent to the list for review (see
"Submitting Patches" below).
-In most cases, we try to wait until we have at least two
+In most cases, we try to wait until we have at least one or two
"Reviewed-by:" replies to a patch posted to the list before
incorporating it into master, so reviews are an important way to help.
We also love a good "Tested-by:" -- the more the merrier.
+Testing
+=======
+
+You can run the test suite much more quickly via "make -j test" (as
+compared to "make test"), at the expense of slightly more confusing
+output (interleaved parallel test output), and inaccurate intermediate
+success/failure counts, but the final counts displayed should be
+correct.
+
+Individual non-Python tests can be run via
+
+ ./wvtest run test/ext/TEST
+
+and if you'd like to see all of the test output, you can omit the
+wvtest run wrapper: `test/ext/TEST`. Individual Python tests can be
+run via
+
+ ./pytest test/int/test_something.py
+
+Internal tests that test bup's code directly are located in test/int,
+and external tests that test bup from the outside, typically by
+running the executable, are located in test/ext.
+
+
+Some aspects of the environment are automatically restored after each
+test via fixtures in conftest.py, including the state of the
+environment variables and the working directory; the latter is reset
+to the top of the source tree.
+
Submitting patches
==================
As mentioned, all patches should be posted to the mailing list for
-review.
-
-You can create a "signed off" (see ./SIGNED-OFF-BY) set of patches in
-./pending, ready for submission to the list, like this:
+review, and must be "signed off" by the author before official
+inclusion (see ./SIGNED-OFF-BY). You can create a "signed off" set of
+patches in ./patches, ready for submission to the list, like this:
- git format-patch -s -o pending origin/master
+ git format-patch -s -o patches origin/master
which will include all of the patches since origin/master on your
current branch. Then you can send them to the list like this:
- git send-email --to bup-list@googlegroups.com --compose patches/*
+ git send-email --to bup-list@googlegroups.com --compose patches/*
The use of --compose will cause git to ask you to edit a cover letter
that will be sent as the first message.
It's also possible to handle everything in one step:
- git send-email -s --to bup-list@googlegroups.com --compose origin/master
+ git send-email -s --to bup-list@googlegroups.com --compose origin/master
and you can add --annotate if you'd like to review or edit each patch
before it's sent.
locally, you may need to configure git to be able to send mail. See
git-send-email(1) for further details.
-Oh, and we do have a ./CODING-STYLE, hobgoblins and all, though don't
+Oh, and we do have a ./CODINGSTYLE, hobgoblins and all, though don't
let that scare you off. We're not all that fierce.
projects / bup.git / blobdiff