Get TZ offset from C localtime, given tm_gmtoff

[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.
 
 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/" 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
 ==================
 
 
 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
 
 
 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).
 
 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.
 "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
 ==================
 
 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:
 
 
 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:
 
 
 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.
 
 and you can add --annotate if you'd like to review or edit each patch
 before it's sent.