Patch available in 'pavlix/next' branch.

Ok, this is handled slightly differently in git master.

Slave devices start activating, do their L2 config, and then enter the IP_CONFIG state where they stop until the master is ready to enslave them, because the master may be start up too and may require some time to do any initial configuration.

Once the master hits stage2/CONFIG it proceeds to enslave any slave waiting in IP_CONFIG state.

This notifies the slave that it is successfully enslaved, and the slave then jumps to SECONDARIES without doing any actual IP configuration.

If the slave finishes with it's L2 config after the master is ready, then the master gets the signal that the slave has finished (and thus entered IP_CONFIG) in slave_state_changed(), where it then enslaves the slave and the slave jumps directly to SECONDARIES.

While slaves do enter the IP_CONFIG state, they don't do any IP configuration because they simply wait to be enslaved.  That is handled by nm_device_activate_stage3_ip_config_start():

	/* If the device is a slave, then we don't do any IP configuration but we
	 * use the IP config stage to indicate to the master we're ready for
	 * enslavement.  Either the master has already enslaved us, in which case
	 * our state transition to SECONDARIES is already queued courtesy of
	 * nm_device_slave_notify_enslaved(), or the master is still activating,
	 * in which case we postpone activation here until the master enslaves us,
	 * which calls nm_device_slave_notify_enslaved().
	 */
	master = nm_active_connection_get_master (NM_ACTIVE_CONNECTION (priv->act_request));
	if (master) {
		if (priv->enslaved == FALSE) {
			nm_log_info (LOGD_DEVICE, "Activation (%s) connection '%s' waiting on master '%s'",
						 nm_device_get_iface (self),
						 nm_connection_get_id (nm_device_get_connection (self)),
						 nm_device_get_iface (master));
		}
		goto out;
	}

Basically, the patch in pavlix/masterslave makes the slave jump directly from stage2/CONFIG to ACTIVATED, which means there's no state where the master can detect that the interface is waiting to be enslaved.  Plus, the slave isn't really "activated" until it's been enslaved, which I think this patch prevents.

So basically, I don't think  "bridging/bonding: disable slave IP configuration (bgo #683205)" is no longer required and can be dropped.

The bug report predated the large bridging/bonding patchset.