This call to try_commit will fail with a timeout when the number of new members is a quorum of the new view. This occurs because the following peers are not yet alive because they haven't been started by `riak_ensemble_manager` on their respective nodes. They haven't been started because `riak_ensemble_manager` hasn't learned of them yet. 

There are actually two issues here. The first issue is a bug. The new fact should only be committed to the original view and hence it should never actually timeout, as it will just be committing to it's existing views. Right now a commit is made to all views, including ones that aren't yet committed.

The second issue, is that even if we commit locally, on the next tick we will try to commit to the new peers. We will run into the same issue where they aren't alive yet. The current proposal to 'fix' this is to add a new async api to the manager that will broadcast in a best effort manner, any new peers to start to all managers. It won't change the state of the ensembles, just start peers that 'might be needed soon', by a commit of a new view for instance. If this occurs in time then the leader will maintain it's leadership. Otherwise, it will drop down to probe state and the manager state will propogate in the normal manner. 

When making these changes it's important to ensure that the peers cannot get into a state where a leader isn't elected and hence the state cannot propogate to start peers that require a leader to be elected. This would cause the system to become unavailable.