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.27 release, we're working on 0.28, and
+although we're not certain which new features will be included, here
+are likely candidates:
-If you have the time and inclination, please help review patches
-posted to the list for inclusion in 0.25. (See "ways to help" below.)
+ - Support for transferring saves between repositories and rewriting
+ branches.
+
+and these are also under consideration:
+
+ - Better VFS performance for large repositories (i.e. fuse, ls,
+ web...).
+
+ - Incremental indexing via inotify.
+
+ - Smarter (and quieter) handling of cross-filesystem metadata.
-We'd like to try to release (0.25) soon, so we're limiting the scope
-of prospective changes -- definitely in-scope:
+ - Support for more general purpose push/pull of branches, saves, and
+ tags between repositories. (See the bup-get patch series.)
- - fixes to the new metadata support
- - fixes for regressions (portability included)
- - fixes for "serious" bugs
- - "simple" fixes
- - documentation improvements
+If you have the time and inclination, please help review patches
+posted to the list, or post your own. (See "ways to help" below.)
More specific ways 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 t/TEST" and
+if you'd like to see all of the test output, you can omit the wvtest
+run wrapper: "t/TEST"
+
+Individual Python tests can be run via "./wvtest run ./wvtest.py
+lib/bup/t/TEST", and as above, you can see all the output by omitting
+the wvtest run wrapper like this: "./wvtest.py lib/bup/t/TEST"
+
+
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: