Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Add ./HACKING and refer to it from README.md.

Signed-off-by: Rob Browning <rlb@defaultvalue.org>
  • Loading branch information...
commit a996c1fc377c567830db8f139ac9fadb0f144e84 1 parent e351481
Rob Browning rlbdv authored
Showing with 100 additions and 0 deletions.
  1. +96 −0 HACKING
  2. +4 −0 README.md
96 HACKING
View
@@ -0,0 +1,96 @@
+
+Conventions? Are you kidding? OK fine.
+
+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.
+
+
+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.
+
+If you have the time and inclination, please help review those patches
+as they're posted to the list. (See below.)
+
+
+More specific ways to help
+==========================
+
+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
+"Submitting Patches" below).
+
+In most cases, we try to wait until we have at least 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.
+
+
+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:
+
+ git format-patch -s -o pending 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/*
+
+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
+
+and you can add --annotate if you'd like to review or edit each patch
+before it's sent.
+
+For single patches, this might be easier:
+
+ git send-email -s --to bup-list@googlegroups.com --annotate -n1 HEAD
+
+which will send the top patch on the current branch, and will stop to
+allow you to add comments. You can add comments to the section with
+the diffstat without affecting the commit message.
+
+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
+let that scare you off. We're not all that fierce.
+
+
+Even More Generally
+===================
+
+It's not like we have a lot of hard and fast rules, but some of the
+ideas here aren't altogether terrible:
+
+ http://www.kernel.org/doc/Documentation/SubmittingPatches
+
+In particular, we've been paying at least some attention to the bits
+regarding Acked-by:, Reported-by:, Tested-by: and Reviewed-by:.
4 README.md
View
@@ -415,6 +415,10 @@ and you can subscribe by sending a message to:
bup-list+subscribe@googlegroups.com
+Please see ./HACKING for additional information, i.e. how to submit
+patches (hint - no pull requests), how we handle branches, etc.
+
+
Have fun,
Avery
Please sign in to comment.
Something went wrong with that request. Please try again.