- use the same gsyncd for master and slave if the connection is local
- use a sane default (ie. /usr/libexec/gsyncd) if the connection is done through ssh

PATCH: http://patches.gluster.com/patch/6366 in master (syncdaemon: configinterface: add support for regexp based pattern-matching sections)

PATCH: http://patches.gluster.com/patch/6367 in master (syncdaemon: add versioning to config file)

PATCH: http://patches.gluster.com/patch/6369 in master (syncdaemon: ensure stdio is flushed before exit)

PATCH: http://patches.gluster.com/patch/6412 in master (mgmt/Glusterd: remove the checks performed for all ops in brick_op)

PATCH: http://patches.gluster.com/patch/6418 in master (mgmt/Glusterd: Make use of regexp pattern-matching sections to set a sane value for remote-gsyncd)

PATCH: http://patches.gluster.com/patch/6505 in master (Revert "syncdaemon: make /usr/libexec/gsyncd the default remote gsyncd (incomplete hacky quickfix)")

PATCH: http://patches.gluster.com/patch/6679 in master (syncdaemon; adding corresponding pcloses to gsyncd invocation via popen)

Verification:

On machine A, install glusterfs with a non-standard prefix; on machine B, install glusterfs with standard prefix (ie. not specifying --prefix for configure). Then create some volumes for both A and B. Local (non-ssh) georeplication setups should work fine out of the box, with zero configuration, both on A and B. ssh setups from A to B should also work out of the box. ssh setups from B to A should work if the setting
gluster gsync configure <master> <slave> remote-gsyncd <gsyncd-path-with-A's-prefix>

is done.

tested with 3.2.0qa13. on master installed glfs- on std path and on slave installed it under /opt/qa13. created symlink at /usr/sbin/gluster binaries to point to /opt/qa13/sbin/gluster & set remote-gsyncd as - 

# gluster volume geo-replication config  :beta1 root.compute.amazonaws.com::slave remote-gsyncd /opt/qa13/libexec/glusterfs/gsyncd

started gsync,master syncs to slave.