X-Git-Url: https://arthur.barton.de/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=HACKING;h=6dc10b19aa95319b5ef804e7757fa03b3924e19f;hb=7031a27141fa053d2a158ff37f8662dc9d2c60f3;hp=88f5b416837be2a73766285cc0496807272b3ff9;hpb=bfa418544ef05efd8b8cca9150d23922f2318205;p=bup.git diff --git a/HACKING b/HACKING index 88f5b41..6dc10b1 100644 --- a/HACKING +++ b/HACKING @@ -7,10 +7,6 @@ Code Branching Model 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. @@ -23,21 +19,28 @@ 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.30 release, we're working on 0.31, 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.) + - Accommodation for the upcoming demise of Python 2, most likely via + support for Python 3. + +and these are also under consideration: + + - Better VFS performance for large repositories (i.e. fuse, ls, + web...). + + - Better VFS caching. + + - Index improvements. + + - Incremental indexing via inotify. -We'd like to try to release (0.25) soon, so we're limiting the scope -of prospective changes -- definitely in-scope: + - Smarter (and quieter) handling of cross-filesystem metadata. - - 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 @@ -55,16 +58,33 @@ 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 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: @@ -93,7 +113,7 @@ Of course, unless your machine is set up to handle outgoing mail 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.