do_bloom(): remove unused "count" variable

[bup.git] / HACKING

diff --git a/HACKING b/HACKING
index f79041d98f18b6ba73ab0adbd2976e8421b6fe1f..d2edcc16ab05aa895ac14290d50db50b8356f07f 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -7,24 +7,36 @@ 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.
 
+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, one of the primary goals is to add support for
-filesystem metadata.  That work is being handled via tmp/pending/meta,
-and we're in the process of trying to vet those patches for master.
-Once that's been done, we're planning to produce a new stable release.
+Now that we've finished the 0.26 release, we're working on 0.27, and
+although we're not certain which new features will be included, here
+are some possible candidates:
+
+  - Support for transferring saves between repositories and rewriting
+    branches.
+
+  - Better VFS performance for large repositories (i.e. fuse, ls,
+    web...).
 
-If you have the time and inclination, please help review those patches
-as they're posted to the list.  (See below.)
+  - Incremental indexing via inotify.
+
+  - Support for rm/gc.
+
+  - Smarter (and quieter) handling of cross-filesystem metadata.
+
+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
@@ -36,7 +48,7 @@ With respect to patches, bup development is handled via the mailing
 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.
@@ -46,24 +58,23 @@ 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 ./pending, 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.