"Fossies" - the Fresh Open Source Software Archive

Member "bup-0.30.1/HACKING" (23 May 2020, 4173 Bytes) of package /linux/privat/bup-0.30.1.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the latest Fossies "Diffs" side-by-side code changes report for "HACKING": 0.30_vs_0.30.1.

    1 
    2 Conventions?  Are you kidding?  OK fine.
    3 
    4 Code Branching Model
    5 ====================
    6 
    7 The master branch is what we consider the main-line of development,
    8 and the last, non-rc tag on master is the most recent stable release.
    9 
   10 Any branch with a "tmp/" prefix might be rebased (often), so keep that
   11 in mind when using or depending on one.
   12 
   13 Any branch with a "tmp/review/" prefix corresponds to a patchset
   14 submitted to the mailing list.  We try to maintain these branches to
   15 make the review process easier for those not as familiar with patches
   16 via email.
   17 
   18 
   19 Current Trajectory
   20 ==================
   21 
   22 Now that we've finished the 0.30.1 release, we're working on 0.31, and
   23 although we're not certain which new features will be included, we've
   24 nearly finished adding support for Python 3, and are also considering:
   25 
   26   - Better VFS performance for large repositories (i.e. fuse, ls,
   27     web...).
   28 
   29   - Better VFS caching.
   30 
   31   - Index improvements.
   32 
   33   - Incremental indexing via inotify.
   34 
   35   - Smarter (and quieter) handling of cross-filesystem metadata.
   36 
   37 If you have the time and inclination, please help review patches
   38 posted to the list, or post your own.  (See "ways to help" below.)
   39 
   40 
   41 More specific ways to help
   42 ==========================
   43 
   44 Testing -- yes please.  
   45 
   46 With respect to patches, bup development is handled via the mailing
   47 list, and all patches should be sent to the list for review (see
   48 "Submitting Patches" below).
   49 
   50 In most cases, we try to wait until we have at least one or two
   51 "Reviewed-by:" replies to a patch posted to the list before
   52 incorporating it into master, so reviews are an important way to help.
   53 We also love a good "Tested-by:" -- the more the merrier.
   54 
   55 
   56 Testing
   57 =======
   58 
   59 You can run the test suite much more quickly via "make -j test" (as
   60 compared to "make test"), at the expense of slightly more confusing
   61 output (interleaved parallel test output), and inaccurate intermediate
   62 success/failure counts, but the final counts displayed should be
   63 correct.
   64 
   65 Individual non-Python tests can be run via "./wvtest run t/TEST" and
   66 if you'd like to see all of the test output, you can omit the wvtest
   67 run wrapper: "t/TEST"
   68 
   69 Individual Python tests can be run via "./wvtest run ./wvtest.py
   70 lib/bup/t/TEST", and as above, you can see all the output by omitting
   71 the wvtest run wrapper like this: "./wvtest.py lib/bup/t/TEST"
   72 
   73 
   74 Submitting patches
   75 ==================
   76 
   77 As mentioned, all patches should be posted to the mailing list for
   78 review, and must be "signed off" by the author before official
   79 inclusion (see ./SIGNED-OFF-BY).  You can create a "signed off" set of
   80 patches in ./patches, ready for submission to the list, like this:
   81 
   82     git format-patch -s -o patches origin/master
   83 
   84 which will include all of the patches since origin/master on your
   85 current branch.  Then you can send them to the list like this:
   86 
   87     git send-email --to bup-list@googlegroups.com --compose patches/*
   88 
   89 The use of --compose will cause git to ask you to edit a cover letter
   90 that will be sent as the first message.
   91 
   92 It's also possible to handle everything in one step:
   93 
   94     git send-email -s --to bup-list@googlegroups.com --compose origin/master
   95 
   96 and you can add --annotate if you'd like to review or edit each patch
   97 before it's sent.
   98 
   99 For single patches, this might be easier:
  100 
  101     git send-email -s --to bup-list@googlegroups.com --annotate -n1 HEAD
  102 
  103 which will send the top patch on the current branch, and will stop to
  104 allow you to add comments.  You can add comments to the section with
  105 the diffstat without affecting the commit message.
  106 
  107 Of course, unless your machine is set up to handle outgoing mail
  108 locally, you may need to configure git to be able to send mail.  See
  109 git-send-email(1) for further details.
  110 
  111 Oh, and we do have a ./CODINGSTYLE, hobgoblins and all, though don't
  112 let that scare you off.  We're not all that fierce.
  113 
  114 
  115 Even More Generally
  116 ===================
  117 
  118 It's not like we have a lot of hard and fast rules, but some of the
  119 ideas here aren't altogether terrible:
  120 
  121   http://www.kernel.org/doc/Documentation/SubmittingPatches
  122 
  123 In particular, we've been paying at least some attention to the bits
  124 regarding Acked-by:, Reported-by:, Tested-by: and Reviewed-by:.