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