[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379279#comment-17379279
]
Matt Pavlovich commented on AMQ-7514:
-------------------------------------
I've created sub-tasks to break-up the effort and I think it should help
delineate the conversation as well. There just isn't a lot of problematic
terminology in the AMQ 5 code base to begin with, and most of the methods are
slated for removal. I'm not opposed to aligning terms, but I do not think we
should align to some terminology that does not have any technical backing in
either code base.
I recommend we define a clear consensus around the precedent in play here. What
is the boundary for terminology alignment? Are we going to rename 'acceptor' to
'transportConnector' in Artemis? Or vice-versa? At this time, the gap in
terminology alignment between the two brokers is very wide. There are more
fundamental user-facing terms that aren't aligned.
Are we in agreement that the terminology alignment goal is only for shared
storage, replicated storage, broker status, and future terms?
>From the original mailing list thread, the point I'd like to emphasize is that
>you can have combinations of replication and shared storage in an
>architecture. I think it is important to have that separated and that the
>terms were derived from there. If we overload 'primary' than it requires more
>training on the user's part to understand.
[~michael.andre.pearce] can you help me understand the value of assigning
meaning to a node? This feels backwards from the industry trend to move away
from designating nodes for a certain purpose. ActiveMQ 5 does not have that
today in any technical capacity.
[~jbertram] there is not currently a configured state, and do not understand
why we'd want to introduce that.
Perhaps it makes more sense to push down the 'tag' term down to the persistence
layer? Attempting to canonicalizing these terms is loaded with gotchas and
further need for translation by users. Those terms can be designated by the
persistence layer and the technology used by that persistence layer. So if
someone is using ZK, those terms can be used 'as-is'. Same for 'BK', custom,
in-house, etc.
As for the broker itself, it is only 'active' or 'standby'. In either case it
represents the _state_ of the broker based on signals from the persistence
adapter layer. Thoughts?
> Replace racially charged terms throughout source code, comments and
> documentation
> ---------------------------------------------------------------------------------
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
> Reporter: Bruce Snyder
> Assignee: Matt Pavlovich
> Priority: Major
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
