The purpose is not really a formal vote (as for a release for instance). It's more to get consensus.
I think we have a consensus. +1 to proceed now :) Regards JB Le dim. 8 mai 2022 à 05:14, Tetreault, Lucas <tetlu...@amazon.com.invalid> a écrit : > Here is the summary of all the votes: > [+1,1,-1,-1000,-1,-1] Leader/Follower > [-1,+1,+1,+1,+1,+1,-1,+1,+1] Primary/Backup > [+1, +1, +1,+1] Active/Passive > [+1] Active/Standby > [+1] capitalist/worker > > It seems like we have consensus on Primary/Backup and Active/Passive as > per Justin's suggestion: > Nouns: Primary/Backup > Adjectives: Active/Passive > > Does this need a formal vote since I didn't get the format right or is > this enough consensus that we can move forward with these terms? > > Thanks, > Lucas > > On 2022-05-06, 9:20 PM, "Michael André Pearce" < > michael.andre.pea...@me.com.INVALID> 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. > > > > My understanding was previous discuss thread was that we leant for for > Primary/Backup > > What I was suggesting as it seemed it wasn’t closed out and it > continues to rumble on was a binary vote per Apache voting on that as the > proposal to end and close it out formally. > > As this is multiple choice this is not a vote thread, for it to be a > vote it needs to be a proposal with a vote of +1/0/-1 on the proposal, not > multi choice. Afaik. > > For the record I stand with the consensus from the previous discussion > as no new arguments are made here. > > As such I would in poll > > > [+1] primary/backup > [-1] Leader/Follower > > > > > Sent from my iPad > > > On 6 May 2022, at 07:26, Tetreault, Lucas > <tetlu...@amazon.com.invalid> wrote: > > > > Hey folks, > > > > I don’t know if I’m actually allowed to call for a vote given I’m > not a committer/PMC member but Michael André Pearce made it clear on Slack > that this was the only way to move this discussion forward and come to a > final conclusion on the issue so here goes nothing. If I’m not supposed to > call for a vote, perhaps someone could “sponsor” this request :) > > > > > > A tweet [1] from a few days ago raised the issue of non-inclusive > terminology in the AWS docs related to ActiveMQ [2] and suggested that we > should replace “masterslave” with a more inclusive name for the network > connector transport. Replacing master/slave nomenclature in ActiveMQ was > raised as a Jira issue in July 2020 [3] and again on the mailing list in > November 2020 [7]. There was some initial work to rename the git branch > from master to main, 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) and Matt Pavlovich drafted a > thorough proposal on the mailing list [6], 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. > > > > > > > > From all the previous discussions, I believe we have two options to > replace master/slave. Artemis will need to layer on a status (e.g.: > active/standby) but I think we can move forward on this vote without > deciding what those terms should be assuming people agree these options > will support having a status layered on top. > > > > > > > > Please submit your +1/-1 vote on the following terms and please > provide specific comments/alternatives if you’re -1 for both options. > > > > [ ] Leader/Follower > > > > [ ] Primary/Backup > > > > > > > > > > > > [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/ > > [6] https://lists.apache.org/thread/rcwogpchjo9p461hqoj6m89q9t2qpqjj > > [7] https://lists.apache.org/thread/5ntnrbz1l92xbvno0s2jxhhf7nbs8d9c > > > > Lucas Tétreault > > Software Development Manager, Amazon MQ > > email: tetlu...@amazon.com<mailto:tetlu...@amazon.com> > > > > > >