I agree with Phill, Noble and Ilan above. The problematic term is "slave" (not master) which I am all for changing if it causes less regression than removing BOTH master and slave. Since some people have pointed out Github changing the "master" terminology, in my personal opinion, it was not a measured response to addressing the bigger problem we are all trying to tackle. There is no concept of a "slave" branch, and "master" by itself is a pretty generic term (Is someone having "mastery" over a skill a bad thing?). I fear all it would end up achieving in the end with Github is a mess of broken build scripts at best. So +1 on "slave" being the problematic term IMO, not "master".
On Thu, Jun 18, 2020 at 8:19 PM Phill Campbell <sirgilli...@yahoo.com.invalid> wrote: > Master - Worker > Master - Peon > Master - Helper > Master - Servant > > The term that is not wanted is “slave’. The term “master” is not a problem > IMO. > > > On Jun 18, 2020, at 3:59 PM, Jan Høydahl <jan....@cominvent.com> wrote: > > > > I support Mike Drob and Trey Grainger. We shuold re-use the > leader/replica > > terminology from Cloud. Even if you hand-configure a master/slave cluster > > and orchestrate what doc goes to which node/shard, and hand-code your > shards > > parameter, you will still have a cluster where you’d send updates to the > leader of > > each shard and the replicas would replicate the index from the leader. > > > > Let’s instead find a new good name for the cluster type. Standalone kind > of works > > for me, but I see it can be confused with single-node. We have also > discussed > > replacing SolrCloud (which is a terrible name) with something more > descriptive. > > > > Today: SolrCloud vs Master/slave > > Alt A: SolrCloud vs Standalone > > Alt B: SolrCloud vs Legacy > > Alt C: Clustered vs Independent > > Alt D: Clustered vs Manual mode > > > > Jan > > > >> 18. jun. 2020 kl. 15:53 skrev Mike Drob <md...@apache.org>: > >> > >> I personally think that using Solr cloud terminology for this would be > fine > >> with leader/follower. The leader is the one that accepts updates, > followers > >> cascade the updates somehow. The presence of ZK or election doesn’t > really > >> change this detail. > >> > >> However, if folks feel that it’s confusing, then I can’t tell them that > >> they’re not confused. Especially when they’re working with others who > have > >> less Solr experience than we do and are less familiar with the > intricacies. > >> > >> Primary/Replica seems acceptable. Coordinator instead of Overseer seems > >> acceptable. > >> > >> Would love to see this in 9.0! > >> > >> Mike > >> > >> On Thu, Jun 18, 2020 at 8:25 AM John Gallagher > >> <jgallag...@slack-corp.com.invalid> wrote: > >> > >>> While on the topic of renaming roles, I'd like to propose finding a > better > >>> term than "overseer" which has historical slavery connotations as well. > >>> Director, perhaps? > >>> > >>> > >>> John Gallagher > >>> > >>> On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski <gerlowsk...@gmail.com > > > >>> wrote: > >>> > >>>> +1 to rename master/slave, and +1 to choosing terminology distinct > >>>> from what's used for SolrCloud. I could be happy with several of the > >>>> proposed options. Since a good few have been proposed though, maybe > >>>> an eventual vote thread is the most organized way to aggregate the > >>>> opinions here. > >>>> > >>>> I'm less positive about the prospect of changing the name of our > >>>> primary git branch. Most projects that contributors might come from, > >>>> most tutorials out there to learn git, most tools built on top of git > >>>> - the majority are going to assume "master" as the main branch. I > >>>> appreciate the change that Github is trying to effect in changing the > >>>> default for new projects, but it'll be a long time before that > >>>> competes with the huge bulk of projects, documentation, etc. out there > >>>> using "master". Our contributors are smart and I'm sure they'd figure > >>>> it out if we used "main" or something else instead, but having a > >>>> non-standard git setup would be one more "papercut" in understanding > >>>> how to contribute to a project that already makes that harder than it > >>>> should. > >>>> > >>>> Jason > >>>> > >>>> > >>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz < > demian.k...@villanova.edu> > >>>> wrote: > >>>>> > >>>>> Regarding people having a problem with the word "master" -- GitHub is > >>>> changing the default branch name away from "master," even in isolation > >>> from > >>>> a "slave" pairing... so the terminology seems to be falling out of > favor > >>> in > >>>> all contexts. See: > >>>>> > >>>>> > >>>> > >>> > https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/ > >>>>> > >>>>> I'm not here to start a debate about the semantics of that, just to > >>>> provide evidence that in some communities, the term "master" is > causing > >>>> concern all by itself. If we're going to make the change anyway, it > might > >>>> be best to get it over with and pick the most appropriate terminology > we > >>>> can agree upon, rather than trying to minimize the amount of change. > It's > >>>> going to be backward breaking anyway, so we might as well do it all > now > >>>> rather than risk having to go through two separate breaking changes at > >>>> different points in time. > >>>>> > >>>>> - Demian > >>>>> > >>>>> -----Original Message----- > >>>>> From: Noble Paul <noble.p...@gmail.com> > >>>>> Sent: Thursday, June 18, 2020 1:51 AM > >>>>> To: solr-user@lucene.apache.org > >>>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature in > >>> Solr > >>>>> > >>>>> Looking at the code I see a 692 occurrences of the word "slave". > >>>>> Mostly variable names and ref guide docs. > >>>>> > >>>>> The word "slave" is present in the responses as well. Any change in > the > >>>> request param/response payload is backward incompatible. > >>>>> > >>>>> I have no objection to changing the names in ref guide and other > >>>> internal variables. Going ahead with backward incompatible changes is > >>>> painful. If somebody has the appetite to take it up, it's OK > >>>>> > >>>>> If we must change, master/follower can be a good enough option. > >>>>> > >>>>> master (noun): A man in charge of an organization or group. > >>>>> master(adj) : having or showing very great skill or proficiency. > >>>>> master(verb): acquire complete knowledge or skill in (a subject, > >>>> technique, or art). > >>>>> master (verb): gain control of; overcome. > >>>>> > >>>>> I hope nobody has a problem with the term "master" > >>>>> > >>>>> On Thu, Jun 18, 2020 at 3:19 PM Ilan Ginzburg <ilans...@gmail.com> > >>>> wrote: > >>>>>> > >>>>>> Would master/follower work? > >>>>>> > >>>>>> Half the rename work while still getting rid of the slavery > >>>> connotation... > >>>>>> > >>>>>> > >>>>>> On Thu 18 Jun 2020 at 07:13, Walter Underwood < > wun...@wunderwood.org > >>>> > >>>> wrote: > >>>>>> > >>>>>>>> On Jun 17, 2020, at 4:00 PM, Shawn Heisey <apa...@elyograg.org> > >>>> wrote: > >>>>>>>> > >>>>>>>> It has been interesting watching this discussion play out on > >>>>>>>> multiple > >>>>>>> open source mailing lists. On other projects, I have seen a VERY > >>>>>>> high level of resistance to these changes, which I find disturbing > >>>>>>> and surprising. > >>>>>>> > >>>>>>> Yes, it is nice to see everyone just pitch in and do it on this > >>> list. > >>>>>>> > >>>>>>> wunder > >>>>>>> Walter Underwood > >>>>>>> wun...@wunderwood.org > >>>>>>> > >>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobs > >>>>>>> erver.wunderwood.org > >>> %2F&data=02%7C01%7Cdemian.katz%40villanova.e > >>>>>>> > >>> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf > >>>>>>> > >>> a366%7C0%7C0%7C637280562684672329&sdata=0GyK5Tlq0PGsWxl%2FirJOVN > >>>>>>> VaFCELlEChdxuLJ5RxdQs%3D&reserved=0 (my blog) > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> ----------------------------------------------------- > >>>>> Noble Paul > >>>> > >>> > > > >
