You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Adam Bordelon <ad...@mesosphere.io> on 2015/06/05 11:27:25 UTC
Re: 答复: [DISCUSS] Renaming Mesos Slave
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 <ek...@wizcorp.jp> wrote:
> +1 for keeping master/slave.
>
> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal) <panyungao@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:zhouwtlord@gmail.com]
>> *发送时间:* 2015年6月5日 10:40
>> *收件人:* 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>:
>>
>> -----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 <erenguven0@gmail.com
>> > <ma...@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 <xiaods@gmail.com
>> > <ma...@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.defelice@gmail.com
>> > <ma...@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 <toenshoff@me.com
>> > <ma...@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 DeFelice 585.241.9488 <tel:585.241.9488> (voice)
>> > 650.649.6071 <tel:650.649.6071> (fax)
>> >
>> >
>> >
>> >
>> > -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)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>
>
Re: 答复: [DISCUSS] Renaming Mesos Slave
Posted by Adam Bordelon <ad...@mesosphere.io>.
James, I was indeed counting "master/slave, no change needed" as -1 for
Item 0, but left them out of the summary for Item 1.
Note that this is a [DISCUSS] thread, not a [VOTE] thread, so we're not
officially voting yet, just gathering ideas from the community. All I was
doing with the (manual) fuzzy matching was trying to summarize what people
have been saying so far. Once the one week discussion period is over, we
will create votable proposals and call for official votes.
On Fri, Jun 5, 2015 at 6:54 AM, Brenden Matthews <br...@diddyinc.com>
wrote:
> +1 to what Adam wrote.
>
> 1. Mesos Worker [Node]
> 2. Mesos Worker or Agent
> 3. No
> 4. Carefully
>
> On Fri, Jun 5, 2015 at 6:31 AM, Sam Salisbury <sa...@gmail.com>
> wrote:
>
>> 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 <ekenler@wizcorp.jp
>>>> <ma...@wizcorp.jp>> wrote:
>>>>
>>>> +1 for keeping master/slave.
>>>>
>>>> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
>>>> <panyungao@huawei.com <ma...@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:zhouwtlord@gmail.com
>>>> <ma...@gmail.com>]
>>>> *发送时间:*2015年6月5日10:40
>>>> *收件人:*user@mesos.apache.org <ma...@mesos.apache.org>
>>>> *主题:*Re: [DISCUSS] Renaming Mesos Slave____
>>>>
>>>> __ __
>>>>
>>>> +1 master/slave, no change needed.____
>>>>
>>>> __ __
>>>>
>>>> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <ankur@malloc64.com
>>>> <ma...@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 <erenguven0@gmail.com
>>>> <ma...@gmail.com>
>>>> > <mailto:erenguven0@gmail.com <ma...@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 <xiaods@gmail.com
>>>> <ma...@gmail.com>
>>>> > <mailto:xiaods@gmail.com <ma...@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.defelice@gmail.com <ma...@gmail.com>
>>>> > <mailto:james.defelice@gmail.com <mailto:
>>>> james.defelice@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 <
>>>> toenshoff@me.com <ma...@me.com>
>>>> > <mailto:toenshoff@me.com <ma...@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>
>>>>
>>>>
>>>>
>>>
>>
>
Re: 答复: [DISCUSS] Renaming Mesos Slave
Posted by Brenden Matthews <br...@diddyinc.com>.
+1 to what Adam wrote.
1. Mesos Worker [Node]
2. Mesos Worker or Agent
3. No
4. Carefully
On Fri, Jun 5, 2015 at 6:31 AM, Sam Salisbury <sa...@gmail.com>
wrote:
> 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 <ekenler@wizcorp.jp
>>> <ma...@wizcorp.jp>> wrote:
>>>
>>> +1 for keeping master/slave.
>>>
>>> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
>>> <panyungao@huawei.com <ma...@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:zhouwtlord@gmail.com
>>> <ma...@gmail.com>]
>>> *发送时间:*2015年6月5日10:40
>>> *收件人:*user@mesos.apache.org <ma...@mesos.apache.org>
>>> *主题:*Re: [DISCUSS] Renaming Mesos Slave____
>>>
>>> __ __
>>>
>>> +1 master/slave, no change needed.____
>>>
>>> __ __
>>>
>>> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <ankur@malloc64.com
>>> <ma...@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 <erenguven0@gmail.com
>>> <ma...@gmail.com>
>>> > <mailto:erenguven0@gmail.com <ma...@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 <xiaods@gmail.com <mailto:
>>> xiaods@gmail.com>
>>> > <mailto:xiaods@gmail.com <ma...@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.defelice@gmail.com <ma...@gmail.com>
>>> > <mailto:james.defelice@gmail.com <mailto:
>>> james.defelice@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 <
>>> toenshoff@me.com <ma...@me.com>
>>> > <mailto:toenshoff@me.com <ma...@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>
>>>
>>>
>>>
>>
>
Re: [DISCUSS] Renaming Mesos Slave
Posted by Brian Topping <br...@gmail.com>.
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/%3c556F52CE.1050600@tampabay.rr.com%3e <https://mail-archives.apache.org/mod_mbox/mesos-user/201506.mbox/%3C556F52CE.1050600@tampabay.rr.com%3E> kind of summarizes it for me.
> On Jun 9, 2015, at 4:55 AM, Lawrence Rau <la...@mac.com> wrote:
>
> +1 no change — keep master/slave
>
>
>> On Jun 8, 2015, at 4:17 PM, Steven Schlansker <ss...@opentable.com> wrote:
>>
>>
>> On Jun 8, 2015, at 1:12 AM, Aaron Carey <ac...@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 [nborod@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:samsalisbury@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 <ekenler@wizcorp.jp
>>> <ma...@wizcorp.jp>> wrote:
>>>
>>> +1 for keeping master/slave.
>>>
>>> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
>>> <panyungao@huawei.com <ma...@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:zhouwtlord@gmail.com
>>> <ma...@gmail.com>]
>>> *发送时间:*2015年6月5日10:40
>>> *收件人:*user@mesos.apache.org <ma...@mesos.apache.org>
>>> *主题:*Re: [DISCUSS] Renaming Mesos Slave____
>>>
>>> __ __
>>>
>>> +1 master/slave, no change needed.____
>>>
>>> __ __
>>>
>>> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <ankur@malloc64.com
>>> <ma...@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 <erenguven0@gmail.com <ma...@gmail.com>
>>>> <mailto:erenguven0@gmail.com <ma...@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 <xiaods@gmail.com <ma...@gmail.com>
>>>> <mailto:xiaods@gmail.com <ma...@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.defelice@gmail.com <ma...@gmail.com>
>>>> <mailto:james.defelice@gmail.com <ma...@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 <toenshoff@me.com <ma...@me.com>
>>>> <mailto:toenshoff@me.com <ma...@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>
>>>
>>
>
Re: [DISCUSS] Renaming Mesos Slave
Posted by Lawrence Rau <la...@mac.com>.
+1 no change — keep master/slave
> On Jun 8, 2015, at 4:17 PM, Steven Schlansker <ss...@opentable.com> wrote:
>
>
> On Jun 8, 2015, at 1:12 AM, Aaron Carey <ac...@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 [nborod@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:samsalisbury@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 <ekenler@wizcorp.jp
>> <ma...@wizcorp.jp>> wrote:
>>
>> +1 for keeping master/slave.
>>
>> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
>> <panyungao@huawei.com <ma...@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:zhouwtlord@gmail.com
>> <ma...@gmail.com>]
>> *发送时间:*2015年6月5日10:40
>> *收件人:*user@mesos.apache.org <ma...@mesos.apache.org>
>> *主题:*Re: [DISCUSS] Renaming Mesos Slave____
>>
>> __ __
>>
>> +1 master/slave, no change needed.____
>>
>> __ __
>>
>> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <ankur@malloc64.com
>> <ma...@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 <erenguven0@gmail.com <ma...@gmail.com>
>>> <mailto:erenguven0@gmail.com <ma...@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 <xiaods@gmail.com <ma...@gmail.com>
>>> <mailto:xiaods@gmail.com <ma...@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.defelice@gmail.com <ma...@gmail.com>
>>> <mailto:james.defelice@gmail.com <ma...@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 <toenshoff@me.com <ma...@me.com>
>>> <mailto:toenshoff@me.com <ma...@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>
>>
>
Re: [DISCUSS] Renaming Mesos Slave
Posted by Steven Schlansker <ss...@opentable.com>.
On Jun 8, 2015, at 1:12 AM, Aaron Carey <ac...@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 [nborod@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:samsalisbury@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 <ekenler@wizcorp.jp
> <ma...@wizcorp.jp>> wrote:
>
> +1 for keeping master/slave.
>
> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
> <panyungao@huawei.com <ma...@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:zhouwtlord@gmail.com
> <ma...@gmail.com>]
> *发送时间:*2015年6月5日10:40
> *收件人:*user@mesos.apache.org <ma...@mesos.apache.org>
> *主题:*Re: [DISCUSS] Renaming Mesos Slave____
>
> __ __
>
> +1 master/slave, no change needed.____
>
> __ __
>
> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <ankur@malloc64.com
> <ma...@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 <erenguven0@gmail.com <ma...@gmail.com>
> > <mailto:erenguven0@gmail.com <ma...@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 <xiaods@gmail.com <ma...@gmail.com>
> > <mailto:xiaods@gmail.com <ma...@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.defelice@gmail.com <ma...@gmail.com>
> > <mailto:james.defelice@gmail.com <ma...@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 <toenshoff@me.com <ma...@me.com>
> > <mailto:toenshoff@me.com <ma...@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>
>
Re: 答复: [DISCUSS] Renaming Mesos Slave
Posted by Alex Rukletsov <al...@mesosphere.com>.
While I'm apathetic to changing the name, I think we should do more than
just voting on an alternate name in case we decide to proceed and replace
the master/slave terminology. Such change is very expensive and it makes
sense to do it once than to rush and pick up an ambiguous term. If we make
this step, we can use it as an opportunity to choose a *better* name for
key Mesos components.
My suggestion is to add pros and cons to every name put in for voting.
Let's back up each proposal with meaningful explanation why this proposal
should be preferred over others. I'll give an example (I will stick to the
current terminology for clarity):
* -1 for 'worker' as it implies the slave process does the actual work,
which is not true and misleading.
* -1 for 'leader/follower' as mesos slaves do not really *follow* the mesos
master; can be confused with leading/shadowing master(s).
* +1 for disambiguating between mesos slave process and mesos slave node:
fwiw, multiple slave processes can be running on the same node.
Some time ago we had an offline discussion about whether master and slave
should actually be different entities. Having a single entity, say,
mesos-agent, that can act either as slave or as master can be beneficial.
Though this is outside of the scope of the current thread, I would like to
keep it in mind and be as general as possible while choosing the name.
Hence, my favourites so far are:
1. Mesos Node [can be disambiguated as Mesos Master Node or Mesos Agent
Node]
2. Mesos Agent
3. No [Mesos Master can mean a particular mode in which a Mesos Agent
currently operates]
4. Start using it in presentations, JIRAs, mailing lists, then proceed to
docs update; change code via deprecation process once new terminology is
settled.
On Mon, Jun 8, 2015 at 10:12 AM, Aaron Carey <ac...@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
>
> 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?
>
>
> ------------------------------
> *From:* Nikolay Borodachev [nborod@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:samsalisbury@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 <ekenler@wizcorp.jp
> <ma...@wizcorp.jp>> wrote:
>
> +1 for keeping master/slave.
>
> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
> <panyungao@huawei.com <ma...@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:zhouwtlord@gmail.com
> <ma...@gmail.com>]
> *发送时间:*2015年6月5日10:40
> *收件人:*user@mesos.apache.org <ma...@mesos.apache.org>
> *主题:*Re: [DISCUSS] Renaming Mesos Slave____
>
> __ __
>
> +1 master/slave, no change needed.____
>
> __ __
>
> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <ankur@malloc64.com
> <ma...@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 <erenguven0@gmail.com
> <ma...@gmail.com>
> > <mailto:erenguven0@gmail.com <ma...@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 <xiaods@gmail.com <mailto:
> xiaods@gmail.com>
> > <mailto:xiaods@gmail.com <ma...@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.defelice@gmail.com <ma...@gmail.com>
> > <mailto:james.defelice@gmail.com <mailto:
> james.defelice@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 <toenshoff@me.com
> <ma...@me.com>
> > <mailto:toenshoff@me.com <ma...@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>
>
>
>
>
>
RE: 答复: [DISCUSS] Renaming Mesos Slave
Posted by Aaron Carey <ac...@ilm.com>.
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
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?
________________________________
From: Nikolay Borodachev [nborod@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:samsalisbury@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 <ek...@wizcorp.jp>
<ma...@wizcorp.jp>>> wrote:
+1 for keeping master/slave.
On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
<pa...@huawei.com> <ma...@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:zhouwtlord@gmail.com<ma...@gmail.com>
<ma...@gmail.com>>]
*����ʱ��:*2015��6��5��10:40
*�ռ���:*user@mesos.apache.org<ma...@mesos.apache.org> <ma...@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>
<ma...@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 <er...@gmail.com> <ma...@gmail.com>>
> <ma...@gmail.com> <ma...@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 <xi...@gmail.com> <ma...@gmail.com>>
> <ma...@gmail.com> <ma...@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 <ja...@gmail.com> <ma...@gmail.com>>
> <ma...@gmail.com> <ma...@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 <to...@me.com> <ma...@me.com>>
> <ma...@me.com> <ma...@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<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>> <tel: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>
> <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<tel:%2B%2081%20%280%293-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>
RE: 答复: [DISCUSS] Renaming Mesos Slave
Posted by Nikolay Borodachev <nb...@adobe.com>.
+1 master/slave – no need to change
From: Sam Salisbury [mailto:samsalisbury@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 <ek...@wizcorp.jp>
<ma...@wizcorp.jp>>> wrote:
+1 for keeping master/slave.
On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
<pa...@huawei.com> <ma...@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:zhouwtlord@gmail.com<ma...@gmail.com>
<ma...@gmail.com>>]
*发送时间:*2015年6月5日10:40
*收件人:*user@mesos.apache.org<ma...@mesos.apache.org> <ma...@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>
<ma...@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 <er...@gmail.com> <ma...@gmail.com>>
> <ma...@gmail.com> <ma...@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 <xi...@gmail.com> <ma...@gmail.com>>
> <ma...@gmail.com> <ma...@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 <ja...@gmail.com> <ma...@gmail.com>>
> <ma...@gmail.com> <ma...@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 <to...@me.com> <ma...@me.com>>
> <ma...@me.com> <ma...@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<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>> <tel: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>
> <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<tel:%2B%2081%20%280%293-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>
Re: 答复: [DISCUSS] Renaming Mesos Slave
Posted by Sam Salisbury <sa...@gmail.com>.
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 <ekenler@wizcorp.jp
>> <ma...@wizcorp.jp>> wrote:
>>
>> +1 for keeping master/slave.
>>
>> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
>> <panyungao@huawei.com <ma...@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:zhouwtlord@gmail.com
>> <ma...@gmail.com>]
>> *发送时间:*2015年6月5日10:40
>> *收件人:*user@mesos.apache.org <ma...@mesos.apache.org>
>> *主题:*Re: [DISCUSS] Renaming Mesos Slave____
>>
>> __ __
>>
>> +1 master/slave, no change needed.____
>>
>> __ __
>>
>> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <ankur@malloc64.com
>> <ma...@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 <erenguven0@gmail.com
>> <ma...@gmail.com>
>> > <mailto:erenguven0@gmail.com <ma...@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 <xiaods@gmail.com <mailto:
>> xiaods@gmail.com>
>> > <mailto:xiaods@gmail.com <ma...@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.defelice@gmail.com <ma...@gmail.com>
>> > <mailto:james.defelice@gmail.com <mailto:
>> james.defelice@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 <
>> toenshoff@me.com <ma...@me.com>
>> > <mailto:toenshoff@me.com <ma...@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>
>>
>>
>>
>
Re: 答复: [DISCUSS] Renaming Mesos Slave
Posted by CCAAT <cc...@tampabay.rr.com>.
"+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 <ekenler@wizcorp.jp
> <ma...@wizcorp.jp>> wrote:
>
> +1 for keeping master/slave.
>
> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal)
> <panyungao@huawei.com <ma...@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:zhouwtlord@gmail.com
> <ma...@gmail.com>]
> *发送时间:*2015年6月5日10:40
> *收件人:*user@mesos.apache.org <ma...@mesos.apache.org>
> *主题:*Re: [DISCUSS] Renaming Mesos Slave____
>
> __ __
>
> +1 master/slave, no change needed.____
>
> __ __
>
> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <ankur@malloc64.com
> <ma...@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 <erenguven0@gmail.com <ma...@gmail.com>
> > <mailto:erenguven0@gmail.com <ma...@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 <xiaods@gmail.com <ma...@gmail.com>
> > <mailto:xiaods@gmail.com <ma...@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.defelice@gmail.com <ma...@gmail.com>
> > <mailto:james.defelice@gmail.com <ma...@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 <toenshoff@me.com <ma...@me.com>
> > <mailto:toenshoff@me.com <ma...@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>
>
>