===== git log ====
commit 2960af47b8db3415fdf40cc50f175fd8d8098578
Author: ShyamsundarR <srangana@redhat.com>
Date:   Mon Nov 20 14:25:48 2017 -0500

    doc: Added initial version of the release notes for 3.13.0
    
    Change-Id: I1b6600cd519578faffe2f67ac0ee3e2555c3cb31
    BUG: 1510012
    Signed-off-by: ShyamsundarR <srangana@redhat.com>
    Signed-off-by: Niels de Vos <ndevos@redhat.com>
    Signed-off-by: karthik-us <ksubrahm@redhat.com>
    [ndevos: added "memory pool in statedump" and "glfs_mem_header" notes]
    [ksubrahm: added notes for "Addition of summary option to heal info"]

commit c1b3c5712a2567990b59d12ff6b334118e26286e
Author: Vishal Pandey <vishpandey2014@gmail.com>
Date:   Thu Nov 2 19:16:26 2017 +0530

    features/worm: new config option to manage deletion of Worm files.
    
    Add a new configuration option worm-files-deletable to
     file-level Worm in order to control behaviour of Worm files upon deletion.
    
    Steps to Test:
    1. Add all the configuration options to a volume to activate file-level-worm
    2. Option features.worm-files-deletable is set to 1 by default.
    3. Create a new file and wait for the retention time to expire.
    4. After retention time expires, do an truncate, rename, unlink, link
       or write to send the file in Worm state.
    5. After that do `rm -f filename`.
    6. The file is successfully removed.
    7. Repeat from step 2 by setting features.worm-files-deletable 0.
       This time deletion should not be successful.
    
    Change-Id: Ibc89861ee296e065330b93a9f9606be5da40af31
    BUG: 1508898
    Signed-off-by: Vishal Pandey <vishpandey2014@gmail.com>

commit fa13ff2f94e16532014f5a6744f494478870e47a
Author: Ravishankar N <ravishankar@redhat.com>
Date:   Wed Aug 16 18:01:17 2017 +0530

    afr: add checks for allowing lookups
    
    Problem:
    In an arbiter volume, lookup was being served from one of the sink
    bricks (source brick was down). shard uses the iatt values from lookup cbk
    to calculate the size and block count, which in this case were incorrect
    values. shard_local_t->last_block was thus initialised to -1, resulting

More commit messages for this ChangeLog can be found at
https://forge.gluster.org/glusterfs-core/glusterfs/commits/v3.13.0rc0
