diff --git a/ChangeLog b/ChangeLog
index 3b1c493..290dddb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1 +1,175554 @@
-ChangeLog is maintained by "git log".
+commit 266ca69d01c8ee7ca04087ced234cf5e392b754a
+Author: Niels de Vos <ndevos@redhat.com>
+Date:   Fri Sep 9 17:28:07 2016 +0200
+
+    doc: release-notes for GlusterFS-3.8.4
+    
+    BUG: 1369049
+    Change-Id: I8f695e867d6043d46c99f55c232eed93580fe3c0
+    Signed-off-by: Niels de Vos <ndevos@redhat.com>
+
+commit 22ea98a31f147bcd1e4643c2b77f503c63b03a4e
+Author: Kotresh HR <khiremat@redhat.com>
+Date:   Tue Sep 6 18:28:42 2016 +0530
+
+    feature/bitrot: Fix recovery of corrupted hardlink
+    
+    Problem:
+    When a file with hardlink is corrupted in ec volume,
+    the recovery steps mentioned was not working.
+    Only name and metadata was healing but not the data.
+    
+    Cause:
+    The bad file marker in the inode context is not removed.
+    Hence when self heal tries to open the file for data
+    healing, it fails with EIO.
+    
+    Background:
+    The bitrot deletes inode context during forget.
+    
+    Briefly, the recovery steps involves following steps.
+       1. Delete the entry marked with bad file xattr
+          from backend. Delete all the hardlinks including
+          .glusters hardlink as well.
+       2. Access the each hardlink of the file including
+          original from the mount.
+    
+    The step 2 will send lookup to the brick where the files
+    are deleted from backend and returns with ENOENT. On
+    ENOENT, server xlator forgets the inode if there are
+    no dentries associated with it. But in case hardlinks,
+    the forget won't be called as dentries (other hardlink
+    files) are associated with the inode. Hence bitrot stube
+    won't delete it's context failing the data self heal.
+    

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