Re: Removing non-inclusive terminology

["Tetreault, Lucas" <te...@amazon.com.INVALID>]

Hey folks, 

I wanted to provide an update on this work. After lots of discussion on GitHub and Slack it has become apparent that I unnecessarily coupled the work to remove non-inclusive terms from the "masterslave" discovery transport to the use of non-inclusive terms in general within ActiveMQ. 

I have updated my original PR to use "staticfailover" instead of "masterslave" for the discovery protocol, as recommended by Robbie Gemmell, which succinctly describes the purpose of the discovery protocol and isn't tied to any particular topology or naming convention. 

I will follow up shortly with a proposal and vote regarding nomenclature to replace the non-inclusive master/slave.

Thanks, 

Lucas
Software Development Manager, Amazon MQ
email: tetlucas@amazon.com

On 2022-04-29, 1:41 PM, "Matt Pavlovich" <ma...@gmail.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    Hey Lucas,

    I think this is a good time to start working in these changes as work starts on 5.18.0.

    My thoughts:

    Pav-1. This is a widely used url, we should take care to transition users. I suggest add this new handler and deprecate masterslave.

    Pav-2. IMHO 'leaderfollower’ is incorrect terminology— in this use case, it really is just a ‘failover’ behavior and there is no relation to the architecture of the target broker(s).

    Thanks,
    Matt Pavlovich

    > On Apr 29, 2022, at 1:08 PM, Tetreault, Lucas <te...@amazon.com.INVALID> wrote:
    >
    > Hey folks,
    >
    > TLDR;
    > I am submitting a PR to rename the "masterslave" network connector transport to "leaderfollower" and I propose that we use leader/follower going forward to replace all references to master/slave.
    >
    > The Long Version:
    > A tweet from a few days ago [1] raised the issue of non-inclusive terminology in the AWS docs [2] and suggested that we should replace masterslave with a more inclusive name for the network connector transport. The AWS docs refer to a feature of ActiveMQ that is a convenience discovery agent: https://activemq.apache.org/networks-of-brokers#masterslave-discovery. We are planning to change the docs to remove the recommendation to use the masterslave transport.
    >
    > Replacing master/slave nomenclature in ActiveMQ was raised in July 2020 [3]. There was some initial work to rename the git branch from master to main and there have been some attempts at making some changes to the code (https://github.com/apache/activemq/pull/679, https://github.com/apache/activemq/pull/714, https://github.com/apache/activemq/pull/788) however we have not been able to come to an agreement on nomenclature so these efforts seem to have stalled out.
    >
    > If we are able to come to an agreement on nomenclature, we can move forward with removing more non-inclusive terminology on the website (I will follow up with some PRs to the website), in discussions with the community and of course in the codebase. This will remove barriers to adoption and make ActiveMQ a more approachable and inclusive project for everyone! Other Apache projects such as Solr and Kafka have moved from master/slave to leader/follower. Leader/follower is also recommended by the IETF [4] and inclusivenaming.org [5] which is supported by companies such as Cisco, Intel, and RedHat. At AWS, we have used active/standby to describe HA deployments, however from previous discussions it's clear that active/standby is not a viable option for this community since 'active' can be used to describe so many things. If we can agree on leader/follower or some alternate we would follow the community's preference and adopt leader/follower to better serve our ActiveMQ users.
    >
    > If we can't come to an agreement on Leader/Follower or some other nomenclature I will, at the very least, create a follow up PR to remove the masterslave transport since it is just a convenience method to use static+failover with ?randomize=false&maxReconnectAttempts=0.
    >
    > [1] https://twitter.com/owenblacker/status/1517156221207212032
    > [2] https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-creating-configuring-network-of-brokers.html#creating-configuring-network-of-brokers-configure-network-connectors
    > [3] https://issues.apache.org/jira/browse/AMQ-7514
    > [4] https://tools.ietf.org/id/draft-knodel-terminology-02.html
    > [5] https://inclusivenaming.org/word-lists/tier-1/
    >
    > Thanks,
    >
    > Lucas Tétreault
    > Software Development Manager, Amazon MQ
    > email: tetlucas@amazon.com
    >