Update base_version to 0.34~ for 0.34 development

[bup.git] / HACKING

diff --git a/HACKING b/HACKING
index 6dc10b19aa95319b5ef804e7757fa03b3924e19f..0c8c719cf685a2bb34e64419cdc821de6050f1f0 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -19,14 +19,20 @@ via email.
 Current Trajectory
 ==================
 
 Current Trajectory
 ==================
 

-Now that we've finished the 0.30 release, we're working on 0.31, and
-although we're not certain which new features will be included, here
-are likely candidates:
+Now that we've finished the 0.33 release, we're working on 0.34, and
+although we're not certain which new features will be included, we're
+considering:

 
 

-  - Accommodation for the upcoming demise of Python 2, most likely via
-    support for Python 3.
+  - Migrating hashsplitting to C.

 
 

-and these are also under consideration:
+  - Automatically splitting trees to avoid having to save large tree
+    objects for large directories even if only a few files have
+    changed or been added (e.g. maildirs).
+
+  - Moving all of the compoents of the index to sqlite.  Right now the
+    main index is an mmapped file, and the hard link and metadata
+    databases are pickled.  As a result the index isn't transactional
+    and suffers from bugs caused by "skew" across the components.

 
   - Better VFS performance for large repositories (i.e. fuse, ls,
     web...).
 
   - Better VFS performance for large repositories (i.e. fuse, ls,
     web...).


@@ -39,6 +45,10 @@ and these are also under consideration:
 
   - Smarter (and quieter) handling of cross-filesystem metadata.
 
 
   - 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, or post your own.  (See "ways to help" below.)
 
 If you have the time and inclination, please help review patches
 posted to the list, or post your own.  (See "ways to help" below.)
 


@@ -46,7 +56,7 @@ posted to the list, or post your own.  (See "ways to help" below.)
 More specific ways to help
 ==========================
 
 More specific ways to help
 ==========================
 

-Testing -- yes please.  
+Testing -- yes please.

 
 With respect to patches, bup development is handled via the mailing
 list, and all patches should be sent to the list for review (see
 
 With respect to patches, bup development is handled via the mailing
 list, and all patches should be sent to the list for review (see


@@ -61,20 +71,34 @@ We also love a good "Tested-by:" -- the more the merrier.
 Testing
 =======
 
 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 tests can be run via
+
+    ./pytest TEST

 
 

-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"
+For example:

 
 

-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"
+    ./pytest test/int/test_git.py
+    ./pytest test/ext/test-ftp

 
 

+If you have the xdist module installed, then you can specify its `-n`
+option to run the tests in parallel (e.g. `./pytest -nauto ...`), or
+you can specify `-j` to make, which will be translated to xdist with
+`-j` becoming `-nauto` and `-jN` becoming `-nN`.
+
+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.
+
+Currently, all pytests must be located in either test/ext or test/int.
+Internal test filenames must match test_*.py, and external tests must
+be located in text/ext and their filenames must match test-* (see
+test/ext/conftest.py for the handling of the latter).  Any paths
+matching those criteria will be automatically collected by pytest.
+
+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
 ==================
 
 Submitting patches
 ==================


@@ -127,3 +151,9 @@ ideas here aren't altogether terrible:
 
 In particular, we've been paying at least some attention to the bits
 regarding Acked-by:, Reported-by:, Tested-by: and Reviewed-by:.
 
 In particular, we've been paying at least some attention to the bits
 regarding Acked-by:, Reported-by:, Tested-by: and Reviewed-by:.

+
+<!--
+Local Variables:
+mode: markdown
+End:
+-->