+1 no change — keep master/slave
> On Jun 8, 2015, at 4:17 PM, Steven Schlansker <sschlans...@opentable.com> > wrote: > > > On Jun 8, 2015, at 1:12 AM, Aaron Carey <aca...@ilm.com> wrote: > >> I've been following this thread with interest, it draws a lot of parallels >> with similar problems my wife faces as a teacher (and I imagine this happens >> in other government/public sector organisations, earlier in this thread >> James pointed me to an interested Wikipedia article which suggested this >> also happens occasionally in software: eg County of Los Angeles in 2003). >> Every few years teachers are told to change the words used to describe >> various things related to kids with minority backgrounds, from >> underprivileged families or with disabilities and so on, usually to stop >> other children from using them as derogatory terms or insults. It works for >> a while and then the pupils catch on and start using the new words and the >> cycle repeats. >> >> I guess the point I'm trying to make here is that if you do decide to change >> the naming of master/slave because some naughty programmers in the community >> have been using the terms offensively, you better make damn sure you choose >> new terms which aren't likely to cause offence in the future and require the >> whole renaming process to run again. Which is why I'm voting for: >> >> +1 Gru/Minion > > Which then is great right up until Universal Pictures sues the Apache > foundation to get "Gru" changed. Plus "master/slave" is immediately obvious > to anyone working in software. I had to search the web to even figure out > what "Gru" was, and then it was not even the first result... ( > http://en.wikipedia.org/wiki/Main_Intelligence_Directorate_%28Russia%29 ) > >> >> There could also be another option: These terms are all being used to >> describe a master/slave relationship, the mesos master is in charge, it >> assigns work to the slaves and ensures that they carry it out. I'd suggest >> that whatever you call this pair, the relationship will always be one of >> domination and servitude. Perhaps what is really needed here is to get rid >> of the concept of a master altogether and re-architect mesos so all nodes in >> the cluster are equal and reach a consensus together about work distribution >> and so on? > > I propose all processes, regardless of function, should be "mesos-comrade" to > ensure none of them feel slighted :) > >> >> >> From: Nikolay Borodachev [nbo...@adobe.com] >> Sent: 06 June 2015 04:34 >> To: user@mesos.apache.org >> Subject: RE: 答复: [DISCUSS] Renaming Mesos Slave >> >> +1 master/slave – no need to change >> >> From: Sam Salisbury [mailto:samsalisb...@gmail.com] >> Sent: Friday, June 05, 2015 8:31 AM >> To: user@mesos.apache.org >> Subject: Re: 答复: [DISCUSS] Renaming Mesos Slave >> >> Master/Minion +1 >> >> On 5 June 2015 at 15:14, CCAAT <cc...@tampabay.rr.com> wrote: >> >> "+1 master/slave, no change needed." is the same as >> "master/slave" I.E. keep the nomenclature as it currently is >> >> This means keep the name 'master' and keep the name 'slave'. >> >> >> Are you applying fuzzy math or kalman filters to your summations below? >> >> It looks to me, tallying things up, Master is kept as it is >> and 'Slave' is kept as it is. There did not seem to be any consensus >> on the new names if the pair names are updated. Or you can vote separately >> on each name? On an real ballot, you enter the choices, >> vote according to your needs, tally the results and publish them. >> Applying a 'fuzzy filter' to what has occurred in this debate so far >> is ridiculous. >> >> Why not repost the question like this or something on a more fair >> voting preference: >> >> ----------------> >> Please vote for your favourite Name-pair in Mesos, for what is currently >> "Master-Slave". Note Master-Slave is the "no change" vote option. >> >> [] Master-Slave >> [] Mesos-Slave >> [] Mesos-Minion >> [] Master-Minion >> [] Master-Follower >> [] Mesos-Follower >> [] Master-worker >> [] Mesos-worker >> [] etc etc >> >> <----------------- >> >> >> Tally the result and go from there. >> James >> >> >> >> >> On 06/05/2015 04:27 AM, Adam Bordelon wrote: >> Wow, what a response! Allow me to attempt to summarize the sentiment so far. >> >> Let's start with the implicit question, >> _0. Should we rename Mesos Slave?_ >> +1 (Explicit approval) 12, including 7 from JIRA >> +0.5 (Implicit approval, suggested alternate name) 18 >> -0.5 (Some disapproval, wouldn't block it) 5, including 1 from JIRA >> -1 (Strong disapproval) 16 >> >> _1. What should we call the "Mesos Slave" node/host/machine?_ >> Worker: +10, -2 >> Agent: +6 >> Follower (+Leader): +4, -1 >> Minion: +2, -1 >> Drone (+Director/Queen): +2 >> Resource-Agent/Provider: +2 >> >> _2. What should we call the "mesos-slave" process (could be the same)?_ >> Pretty much everybody says that it should be the same as the node. >> >> _3. Do we need to rename Mesos Master too?_ >> Most say No, except when slave's new name has a preferred pairing (e.g. >> Follower/Leader) >> >> _4. How will we phase in the new name and phase out the old name?_ >> To calm any fears, we would have to go through a full deprecation cycle, >> introducing the new name in one release, while maintaining >> symlinks/aliases/duplicate-endpoints for the old name. In a subsequent >> release, we can remove the old name/endpoints. As we introduce the new >> Mesos 1.0 HTTP API, we will already be introducing breaking API changes, >> so this would be an ideal time to do a rename. >> >> Whether or not we decide to officially change the name in the code/APIs, >> some organizations are already using alternative terminologies in their >> presentations/scripts. We could at least try to agree upon a recommended >> alternative name for these purposes. >> >> _5. How do we vote on this?_ >> First, FYI: https://www.apache.org/foundation/voting.html >> It seems there are two potentially separate items to vote on: >> >> Prop-A: Rename Mesos-Slave in the code/APIs >> Qualifies as a "code modification", so a negative (binding) vote >> constitutes a veto. Note that there are no -1s from the Mesos PMC yet. >> After this week of discussion where the community is invited to share >> their thoughts/opinions, we will call for an official VOTE from the PMC >> members. The proposal will pass if there are at least three positive >> votes and no negative ones. >> >> Prop-B: Recommended Alternative Name for "Slave" >> This can follow the common format of majority rule. We can gather >> recommendations during this one week discussion period, and then vote on >> the top 2-3 finalists. >> >> On Thu, Jun 4, 2015 at 8:23 PM, Emilien Kenler <eken...@wizcorp.jp >> <mailto:eken...@wizcorp.jp>> wrote: >> >> +1 for keeping master/slave. >> >> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal) >> <panyun...@huawei.com <mailto:panyun...@huawei.com>> wrote: >> >> +1 master/slave. ____ >> >> __ __ >> >> These are only terminologies in software architecture. They >> have different definitions from those of social or political >> view. ____ >> >> __ __ >> >> *发件人:*zhou weitao [mailto:zhouwtl...@gmail.com >> <mailto:zhouwtl...@gmail.com>] >> *发送时间:*2015年6月5日10:40 >> *收件人:*user@mesos.apache.org <mailto:user@mesos.apache.org> >> *主题:*Re: [DISCUSS] Renaming Mesos Slave____ >> >> __ __ >> >> +1 master/slave, no change needed.____ >> >> __ __ >> >> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <an...@malloc64.com >> <mailto:an...@malloc64.com>>:____ >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> +1 master/slave >> >> James made some very good points and there is no technical >> reason for >> wasting time on this. >> >> On 04/06/2015 08:45, James Vanns wrote: >>> +1 master/slave, no change needed. >>> >>> I couldn't agree more. This is a barmy request; master/slave is a >>> well understood common convention (if it isn't well defined). This >>> is making an issue out of something that isn't. Not at least as far >>> as I see it - I don't have a habit of confusing software/systems >>> nomenclature with moral high ground. This would just be a waste of >>> time and not just for developers but for those adopting/who have >>> adopted Mesos. If it were a brand new project at the early stages >>> of just throwing ideas around, then fine - call master/slave >>> whatever you want. Gru/Minion would get my vote if that were the >>> case ;) >>> >>> Cheers, >>> >>> Jim >>> >>> >>> On 4 June 2015 at 16:23, Eren Güven <erenguv...@gmail.com >>> <mailto:erenguv...@gmail.com> >>> <mailto:erenguv...@gmail.com <mailto:erenguv...@gmail.com>>> wrote: >>> >>> +1 master/slave, no change needed >>> >>> Such a change is a waste of time with no technical benefit. Also >>> agree with Itamar, a breaking change like this will cause upgrade >>> pains. >>> >>> Cheers >>> >>> On 4 June 2015 at 17:08, tommy xiao <xia...@gmail.com >>> <mailto:xia...@gmail.com> >>> <mailto:xia...@gmail.com <mailto:xia...@gmail.com>>> wrote: >>> >>> +1 to James DeFelice. I don't feel the name is confuse for any >>> circumstance. >>> >>> 2015-06-04 22:06 GMT+08:00 James DeFelice <james.defel...@gmail.com >>> <mailto:james.defel...@gmail.com> >>> <mailto:james.defel...@gmail.com <mailto:james.defel...@gmail.com>>>: >>> >>> -1 master/worker -1 master/agent -1 leader/follower >>> >>> +1 master/slave; no change needed >>> >>> There's no technical benefit **at all** to a terminology change at >>> this point. If people want to change the names in their client >>> presentations that's fine. Master/slave conveys specific meaning >>> that is lost otherwise. In this context of this project (and >>> elsewhere in Engineering-related fields) the terms are technical >>> jargon and have no social implications within such context. >>> >>> >>> On Thu, Jun 4, 2015 at 9:53 AM, Till Toenshoff <toensh...@me.com >>> <mailto:toensh...@me.com> >>> <mailto:toensh...@me.com <mailto:toensh...@me.com>>> wrote: >>> >>>> 1. Mesos Worker [node/host/machine] 2. Mesos Worker [process] 3. >>>> No, master/worker seems to address the issue with less changes. >>>> 4. Begin using the new name ASAP, add a disambiguation to the >>>> docs, and change old references over time. Fixing the "official" >>>> name, even before changes are in place, would be a good first >>>> step. >>> >>> +1 >>> >>> >>> >>> >>> -- James DeFelice585.241.9488 <tel:585.241.9488> <tel:585.241.9488 >> <tel:585.241.9488>> (voice) >>> 650.649.6071 <tel:650.649.6071> <tel:650.649.6071 >> <tel:650.649.6071>> (fax) >>> >>> >>> >>> >>> -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com >>> <http://gmail.com> >>> <http://gmail.com> >>> >>> >>> >>> >>> >>> -- -- Senior Code Pig Industrial Light & Magic >> -----BEGIN PGP SIGNATURE----- >> >> iQEcBAEBAgAGBQJVcHhwAAoJEOSJAMhvLp3L8E4H/2ug5bAs5S7sZrGVZyp4vdki >> tEd67eQDu1gXCV1fC6VqStnlGG9UHG95/RaCkiLLEmtbYBIY4f+6Urbwoo0P4Qyh >> sU4Z0y3cdXkibH1DTIwT3tRXa/yp9Msx+KAI6NqXvfOtnLVXXtT4nKD9BCQ/+u98 >> afvICT1z25lBiYjBaZaVlrJRFtZkmRzVhwWiSnmtfyBfyvwbg8tEGoR1mqf3h7D5 >> ZpxTUvjLc1sF0NNLFTt30ReJfynOGY0tNfozi9Ubf5Hs7/3xfuHSBDVDm1+2EP4/ >> cHEMs2S0+54JsgSTGBGq4PGL/nKQ8vuwjzVihgQXpA3CU8QBikuvdRc/UBwDaR0= >> =niNh >> -----END PGP SIGNATURE-----____ >> >> __ __ >> >> >> >> >> -- >> <http://www.wizcorp.jp/> Emilien Kenler >> Server Engineer | Wizcorp Inc. <http://www.wizcorp.jp/> >> ------------------------------------------------------------------------ >> TECH . GAMING . OPEN-SOURCE WIZARDS >> + 81 (0)3-4550-1448|Website <http://www.wizcorp.jp/>|Twitter >> <https://twitter.com/Wizcorp>|Facebook >> <http://www.facebook.com/Wizcorp>|LinkedIn >> <http://www.linkedin.com/company/wizcorp> >> >
