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 ?C 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> >
