The moment it costs money for deployments to change these names, I'm "+1 no change — keep master/slave".
https://mail-archives.apache.org/mod_mbox/mesos-user/201506.mbox/%[email protected]%3e <https://mail-archives.apache.org/mod_mbox/mesos-user/201506.mbox/%[email protected]%3E> kind of summarizes it for me. > On Jun 9, 2015, at 4:55 AM, Lawrence Rau <[email protected]> wrote: > > +1 no change — keep master/slave > > >> On Jun 8, 2015, at 4:17 PM, Steven Schlansker <[email protected]> >> wrote: >> >> >> On Jun 8, 2015, at 1:12 AM, Aaron Carey <[email protected]> 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 [[email protected]] >>> Sent: 06 June 2015 04:34 >>> To: [email protected] >>> Subject: RE: 答复: [DISCUSS] Renaming Mesos Slave >>> >>> +1 master/slave – no need to change >>> >>> From: Sam Salisbury [mailto:[email protected]] >>> Sent: Friday, June 05, 2015 8:31 AM >>> To: [email protected] >>> Subject: Re: 答复: [DISCUSS] Renaming Mesos Slave >>> >>> Master/Minion +1 >>> >>> On 5 June 2015 at 15:14, CCAAT <[email protected]> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> +1 for keeping master/slave. >>> >>> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal) >>> <[email protected] <mailto:[email protected]>> 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:[email protected] >>> <mailto:[email protected]>] >>> *发送时间:*2015年6月5日10:40 >>> *收件人:*[email protected] <mailto:[email protected]> >>> *主题:*Re: [DISCUSS] Renaming Mesos Slave____ >>> >>> __ __ >>> >>> +1 master/slave, no change needed.____ >>> >>> __ __ >>> >>> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <[email protected] >>> <mailto:[email protected]>>:____ >>> >>> -----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 <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>>: >>>> >>>> -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 <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> 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> >>> >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
