[
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170458#comment-17170458
]
Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 11:17 PM:
---------------------------------------------------------------
hey guys, I opened a PR for both but the longer we delay on merging the more
trouble it will be to get it in. So I will update the leader/follower one (the
first one actually) that fell behind a bit and didn't get as much love, but
please don't hesitate to continue to work on whichever of the two PRs you
prefer because I'm frankly sick of reading the words master and slave. It's
really stressful.
And [~tflobbe] I think your analysis sheds light on the fact that
leader/follower is not what's happening in non-SolrCloud mode. Replicas are not
replicas of a leader. They are replicas. If the "leader" fails the state of the
cluster is very different for an end-user managing the cluster compared to when
a leader goes down in SolrCloud. They are very different.
This is an aside: Can I ask why you support colliding terms for reasons other
than you "personally like to use 'leader/follower?'"
As I said, I really don't care. I just want it to leave the code base so I
never have to see it again, same with others who don't like to think about it.
was (Author: marcussorealheis):
hey guys, I opened a PR for both but the longer we delay on merging the more
trouble it will be to get it in. So I will keep update the leader/follower one
that fell behind a bit and didn't get as much love, but please don't hesitate
to continue to work on whichever of the two PRs you prefer because I'm frankly
sick of reading the words master and slave. It's really stressful.
And [~tflobbe] I think your analysis sheds light on the fact that
leader/follower is not what's happening in non-SolrCloud mode. Replicas are not
replicas of a leader. They are replicas. If the "leader" fails the state of the
cluster is very different for an end-user managing the cluster compared to when
a leader goes down in SolrCloud. They are very different.
Can I ask why you support colliding terms for reasons other than you
"personally like to use 'leader/follower?'"
> Remove Master and Slave from Code Base and Docs
> -----------------------------------------------
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: master (9.0)
> Reporter: Marcus Eagan
> Priority: Critical
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where
> he lost his legs, and then he was back to being a sharecropper somehow after
> the war. Crazy, I know. I don't know if the world still called his job
> sharecropping in 1993, but he was basically a slave—in America. He lived in
> the same shack that his father, and his grandfather (born a slave) lived in
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was
> actually born a slave, freed shortly after birth by his owner father. I never
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This
> master/slave shit is archaic and misleading on technical grounds. Thankfully,
> there's only a handful of files in code and documentation that still talk
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or
> wants to do the grunt work to help my stress levels, I will open the pull
> request myself in effort to make this project and community more inviting to
> people of all backgrounds and histories. We can have leader/follower, or
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the
> garbage.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
