Terminology Updates

[Slide]

Hi Everyone,

 

Back in the Jenkins 2.0 days, it was decided (rightfully so) to deprecate the term "slave" as it was used in the Jenkins project. There has been some significant progress made on this effort by many contributors with some remaining effort needing to be done (see the JENKINS-42816 EPIC). The agent terminology cleanup is recognized as a major initiative in the project, and it is listed on the Jenkins Public Roadmap Draft. We have some additional terminology that we would like to look at deprecating and replacing within the Jenkins project.

 

The following terminology are items that we would like to replace with possible options. We would like this discussion to be civil, these words have powerful negative meanings for many people and we want to make sure, as a project, that we are using terms which are not negative. Please reply with opinions on the possible replacements that the Advocacy and Outreach SIG came up with, or others if you have additional ideas. 

 

• Master ->

• Host

• Server

• Control Plane

• Whitelist/Blacklist ->

• Allowlist/Denylist

• Allowlist/Blocklist

 

If there are other terms that you have seen in the Jenkins project that may need to be deprecated and replaced, please contact the Jenkins Governance Board members (jenkins...@googlegroups.com) with your concerns.

 

Regards,

 

Alex Earl

Jenkins Governance Board Member

--

Website: http://earl-of-code.com

[Marky Jackson]

First and foremost, this is extremely important and I am thankful to be a part of a community addressing this. I want to thank those that protested and continue to do so. 

I am so sorry these offensive terms are even a thing and I am even more sorry any person has to suffer.

My vote is:

- Host

- Allowlist/Denylist

On Jun 11, 2020, at 8:34 PM, Slide <slide...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVe14X%2B8u8Vy7EGW30GW-i96rxPSMZm7-qMdzM6VcPtcSg%40mail.gmail.com.

[Richard Bywater]

Can I suggest "Controller" as a possible replacement for Master? Host/Server are a little too ambiguous in this context and I don't really like the term "Control Plane".

Allowlist/Denylist would be my suggested replacements for the lists although personally I'd prefer it written as AllowList/DenyList anywhere it appears in mixed case :)

Richard.

--

[Marky Jackson]

The concern with controller may be a conflict with Kubernetes on Jenkins given the same name. This was originally my suggestion but than I remembered I was also part of renaming in that community.

> On Jun 11, 2020, at 9:02 PM, Richard Bywater <ric...@bywater.nz> wrote:
>

[Richard Bywater]

Good point. I actually wonder if Manager is a reasonable replacement?

[Marky Jackson]

It is a suggestion for consideration if you would like.

On Jun 11, 2020, at 9:35 PM, Richard Bywater <ric...@bywater.nz> wrote:



--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%40mail.gmail.com.

[Oleg Nenashev]

I am +1 for changing the terminology, and I encourage Jenkins contributors to participate in this effort. It is not something we could change in a minute, but we could do a gradual cleanup and improve the overall documentation while doing so.

I am -1 w.r.t "host" due to the following reasons:

• Host term is very generic, it has thousands of usages in Jenkins https://github.com/search?q=org%3Ajenkinsci+host&type=Code. Choosing this term will require a careful cleanup to avoid confusion in user documentation and the codebase
• "agent host" is often used to describe target hosts for outbound agents

My suggestion would be to consider a "Jenkins server" term. You can see that such a term is already used in our codebase, website and on 3rd party resources.

Best regards,

Oleg

On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:

It is a suggestion for consideration if you would like.

On Jun 11, 2020, at 9:35 PM, Richard Bywater <ric...@bywater.nz> wrote:



Good point. I actually wonder if Manager is a reasonable replacement?

On Fri, 12 Jun 2020 at 16:04, Marky Jackson <marky....@gmail.com> wrote:

The concern with controller may be a conflict with Kubernetes on Jenkins given the same name. This was originally my suggestion but than I remembered I was also part of renaming in that community.

> On Jun 11, 2020, at 9:02 PM, Richard Bywater <ric...@bywater.nz> wrote:
>

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

[Jeff Thompson]

My favorite is "Jenkins server" or something like that. There are already existing usages and it's reasonably explanatory. Something with "manager" could also work, but I don't find the term as clean and clear.

Outside of bias issues, one of the problems with whitelist and blacklist is that the terms don't really say what they do. Sometimes the interpretation depends on which way you're looking at it. Somewhat similar to whether a class hierarchy goes up or down.

"AllowList" and "DenyList" are good matching pairs that convey more semantics about what they do.

In other discussions we have noted that not all usages of whitelist/blacklist fall into the same behavioral meaning. Sometimes we will need to use different terminology to better convey the meaning.

Jeff

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com.

[Gavin Mogan]

Control plane works but is a mouthfull. Controller works, but as others pointed out, could easily be confused in the k8s world.

the other two (Host and Server) are way too generic to convey meaning if you don't know the system.

You could go silly like POTUJ (President of the United Jenkins) or JOTUJ (Jenkins of the United Jenkins).

Jenkins Brain

Jenkins President

Jenkins CEO

Jenkins Manager

Jenkins Foreman

Jenkins Governor

Jenkins Super / Super Jenkins

Jenkins Taskmaster

Jenkins Boss

Jenkins Leader

Jenkins Overlord

A lot came from https://www.wordhippo.com/what-is/another-word-for/controller.html

I personally think without the slave context, master is pretty accurate. To be absolutely honest, if it has more syllables than the current, people are super likely to stick with the existing wording (Slave-1 vs Agent-2) cause its easier to say/remember.

Gavin

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.com.

[Mark Waite]

My favorite is Jenkins server.  I'll use whatever term is ultimately selected, but "Jenkins server" is easier for me than "Control Plane".

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.com.

[Vlad Silverman]

I agree, “Jenkins Server” reflects primary functionality and definitely makes sense.

Thx, Vlad

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH%3DNGuf%2BEOoh9gXyOY53vx761aV-w4V07hA7SxwZ%2B_Q1A%40mail.gmail.com.

[Matt Sicker]

I also like Jenkins Server as a simple name.

Other ideas: JenkinsD (like SystemD or any daemon), Jenkins Principal
(matches the principal/agent paradigm of agents executing code on
behalf of the principal).

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7EF2760C-0B57-42AA-A600-B55E557956D3%40gmail.com.



--
Matt Sicker
Senior Software Engineer, CloudBees

[Marky Jackson]

I like Jenkins Server too

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oxiMsarDuQp8KcgUcv08TVtHFBpsz2m4qRECdBo%2BvhzGw%40mail.gmail.com.

[Slide]

Jenkins Server makes sense to me as well. I'll add as a topic for the next Governance meeting. Please also make sure and weigh in on AllowList/DenyList and it's other derivatives.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F2B3AC63-DD98-48A4-A5F2-064D9336C1BD%40gmail.com.

[Jeff]

My vote:

• Master -> Controller (Host and Server are too broad, and Control Plane is to verbose)
  
• Whitelist/Blacklist -> Allowlist/Blocklist
  

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVe14X%2B8u8Vy7EGW30GW-i96rxPSMZm7-qMdzM6VcPtcSg%40mail.gmail.com.

[Richard Bywater]

> I personally think without the slave context, master is pretty accurate

That's a good point. I did a quick search and noticed that Apache Mesos renamed to agents a few years back but left the main controller as being a "master" so there is some precedent there.

Richard.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuE1g6-xW0DtSjYsv9F%2B-WNmv-WUrtM68nbZPWK%3DdfJ5w%40mail.gmail.com.

[Mez Pahlan]

Why not extend the butler analogy? Majordomo. Or MD for short?

[Arnaud Héritier]

I prefer server. It’s generic but short. 

Allowlist is ok. I have no preference between denylist and blocklist. Depending of the context where it is used it could perhaps be includes/excludes. 

Arnaud 

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVe14X%2B8u8Vy7EGW30GW-i96rxPSMZm7-qMdzM6VcPtcSg%40mail.gmail.com.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Daniel Beck]

> On 12. Jun 2020, at 20:05, Slide <slide...@gmail.com> wrote:
>
> Jenkins Server makes sense to me as well. I'll add as a topic for the next Governance meeting.

It seems as if this thread so far lacks considerations regarding the implementation of such a decision. This is concerning because a superficially good solution may well turn out to bring challenges when it comes to implementing them.

For example, right now, master is at /computer/(master)/ and its self-label (to build jobs on it) is 'master'. What would those look like with the term 'Jenkins Server'? URLs with spaces in them are annoying due to percent-encoding. While labels support spaces, it's a fairly annoying syntax to type and autocompletion for them doesn't work properly. IOW, this is going to be more difficult if we choose a composite term.

Similarly, it could make sense for us to consider how the term would be translated into some of the more commonly used languages. Some of the proposed terms are probably not easily translated. ('Server' should be fine as it's such a common term in tech. 'Majordomo' OTOH?)

It might even make sense to separate the "UI" part from the "node" part: Jenkins server makes sense for the former. A different term might make more sense for the latter (and it's even clearer with terms like 'controller': the master node controls nothing). 'Primary' could work except it sounds like it's a good idea to build there. 'Local' perhaps?

> Please also make sure and weigh in on AllowList/DenyList and it's other derivatives.

FWIW since I've struggled to think of notable examples in Jenkins outside system properties and basically deprecated features like agent-to-master ('agent-to-jenkins-server'?) security: In-Process Script Approval (Script Security) has whitelists.



P.S.: But perhaps let's throw some consideration about the scope of necessary changes of any term into the mix so we don't end up with a never-ending mess like for 'agent', but are prepared to implement this more quickly.

Assuming a similar scope (fix all the UI, fix the few locations in the code that aren't breaking changes, fix Javadoc, skip breaking code changes and introduce compatibility fallbacks like supporting both 'agent.jar' and 'slave.jar' URLs):

- So far we probably should add the label 'master' to that node (only) when upgrading from an older Jenkins. Otherwise builds may be blocked.
- Show an admin monitor if any other node has the new self-label for the replacement term. This can result in unexpected node assignment decisions.
- …?

[James Nord]

Jenkins server is ambiguous it has as many minus votes as I can put (limited to one)

login to the Jenkins server and run service start Jenkins.....

login to the Jenkins server and create a new job

whatever we choose it can not be confused with the host/is/server/machine that the is process runs in.

[Mark Waite]

On Sat, Jun 13, 2020 at 1:19 PM James Nord <james...@gmail.com> wrote:

Jenkins server is ambiguous it has as many minus votes as I can put (limited to one)

login to the Jenkins server and run service start Jenkins.....

Wouldn't that be better phrased as "login to Linux and run `systemctl start jenkins`" or "login to Windows and run `sc start Jenkins`"?  In this case, the focus of "login" is the operating system, not Jenkins.

 

login to the Jenkins server and create a new job

Wouldn't that be better phrased as "login to Jenkins and create a new job"?  In this case, the focus of "login" is Jenkins and not the operating system.

 

whatever we choose it can not be confused with the host/is/server/machine that the is process runs in.

I'm not sure of a term that does not risk confusion with the host/machine/environment where the process runs.  We already need to be clear in our phrasing today to assure that readers know whether the action should be applied to the host operating system (your first example) or the Jenkins process (your second example).

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2d33082f-c697-4bfe-a007-56383ac973e1o%40googlegroups.com.

[James Nord]

you correctly Pou ted out my examples where rubbish.
but you can not talk about the Jenkins server and know what the other is talking about without saying, you mean Linux or the java process thing it's a recepie for disaster or turning 2 words into 6 every time you want to use it.

today sure we say login to jenkins using my example. but asking say what's the memory of the Jenkins server..

when you want to be OS agnostic (not all Jenkins run in Linux) refering to the server is highly advantageous.

I just see this as something that would bite us in the future, irrespective of any technical issues (raised by Daniel)

what if we break the Jenkins monolith down into multiple processes, the cloud native Sig is starting up again iirc and who knows where that will take us...

[Mark Waite]

On Sat, Jun 13, 2020 at 3:04 PM James Nord <james...@gmail.com> wrote:

but you can not talk about the Jenkins server and know what the other is talking about without saying, you mean Linux or the java process thing it's a recepie for disaster or turning 2 words into 6 every time you want to use it.

today sure we say login to jenkins using my example. but asking say what's the memory of the Jenkins server..

when you want to be OS agnostic (not all Jenkins run in Linux) refering to the server is highly advantageous. 

I see.  So you would reserve the word "server" for a higher level than the Jenkins java process.  That is reasonable, though it means we need a different word or phrase than "server"

 

I just see this as something that would bite us in the future, irrespective of any technical issues (raised by Daniel)

I like Daniel's idea of more precisely describing the scope of the changes related to this renaming and how they would be implemented.  I'll reply there with some ideas for discussion.

 

[Slide]

Yes, the whole point of this thread is for discussion of all aspects, including all the technical issues that we will have. 

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEDr7b6sMVVFBBxd4J8FfFLCFGzhVpFDDHpXQxuvOxGxA%40mail.gmail.com.

--

Website: http://earl-of-code.com

[Ben Castellucci]

I don't really ever weigh in on things but this time I'd like to.

I think its safe to say no one wants anything with a space or special chars, due to obvious technical issues.

In that vein, 'Jenkins Server' could have such technical implications plus it is very broad.

So we're left with one word alternatives, so here's a short list of me just brain storming a little:

    - controller (this is my favorite but I think someone objected a while back)

    - commander

    - coordinator

    - leader (a bit of a stretch)

    - primary (sounds ok to me - 'primary node', 'agent node', etc.)

    - first

    - main

Most of these (with the exception maybe of 'commander' and 'leader') already appear in the vernacular & are well known.

My vote is 'controller' or 'primary'.

Thanks,

Ben

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfc0kdVi_RDiKp4RATipbwPBAMYo%3Df20PoNhaMSw%2B5Y5w%40mail.gmail.com.

[Mark Waite]

Here's my attempt at more precise details.

On Sat, Jun 13, 2020 at 3:02 AM Daniel Beck <m...@beckweb.net> wrote:

> On 12. Jun 2020, at 20:05, Slide <slide...@gmail.com> wrote:
>
> Jenkins Server makes sense to me as well. I'll add as a topic for the next Governance meeting.

It seems as if this thread so far lacks considerations regarding the implementation of such a decision. This is concerning because a superficially good solution may well turn out to bring challenges when it comes to implementing them.

For example, right now, master is at /computer/(master)/ and its self-label (to build jobs on it) is 'master'. What would those look like with the term 'Jenkins Server'? URLs with spaces in them are annoying due to percent-encoding. While labels support spaces, it's a fairly annoying syntax to type and autocompletion for them doesn't work properly. IOW, this is going to be more difficult if we choose a composite term.

Similarly, it could make sense for us to consider how the term would be translated into some of the more commonly used languages. Some of the proposed terms are probably not easily translated. ('Server' should be fine as it's such a common term in tech. 'Majordomo' OTOH?)

It might even make sense to separate the "UI" part from the "node" part: Jenkins server makes sense for the former. A different term might make more sense for the latter (and it's even clearer with terms like 'controller': the master node controls nothing). 'Primary' could work except it sounds like it's a good idea to build there. 'Local' perhaps?

I like the idea of separating the "UI" part from the "node" part.

 

> Please also make sure and weigh in on AllowList/DenyList and it's other derivatives.


FWIW since I've struggled to think of notable examples in Jenkins outside system properties and basically deprecated features like agent-to-master ('agent-to-jenkins-server'?) security: In-Process Script Approval (Script Security) has whitelists.



P.S.: But perhaps let's throw some consideration about the scope of necessary changes of any term into the mix so we don't end up with a never-ending mess like for 'agent', but are prepared to implement this more quickly.

Assuming a similar scope (fix all the UI, fix the few locations in the code that aren't breaking changes, fix Javadoc, skip breaking code changes and introduce compatibility fallbacks like supporting both 'agent.jar' and 'slave.jar' URLs):

- So far we probably should add the label 'master' to that node (only) when upgrading from an older Jenkins. Otherwise builds may be blocked.
- Show an admin monitor if any other node has the new self-label for the replacement term. This can result in unexpected node assignment decisions.
- …?

Using the word 'valet' instead of 'master' to refer to the node that executes inside the original Jenkins Java process.  Replace it with the term you prefer

• Redirect requests from /computer/(master)/ to /computer/(valet)/
  
• Assign the label 'valet' to the node that executes inside the original Jenkins process
• Assign the NODE_NAME="valet" env var to that node instead of NODE_NAME="master"
  
• Replace 'master' with 'valet' in help-label.html for AbstractProject
  
• Change display name of root node from 'master' to 'valet'
• Change the Jenkins#getSelfLabel() to return the label atom of "valet" instead of "master"
• Show an admin monitor if any other agent has the label 'valet'
• Convert tests that reference agent labeled 'master' to use label 'valet'

Things that would not change:

• The jenkins.security.Roles (internal concept only, not shown to users)
• Name of the key file in security/master.key (internal concept, not shown to users)

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4F7F25FE-09BD-47C0-9BE8-5EAA28FA8C18%40beckweb.net.

[Oleg Nenashev]

It would be better to handle implementation details should in separate threads. Technical complexity is implied here. Actual cleanup will of deprecated terminology is likely to take years, and we will have plenty of time to deep dive on it. Let's focus on terminology.

I like Daniel's suggestion about using separate terms depending on the case, e.g. Jenkins Web UI, Jenkins agent controller, etc. We already have examples of multi-tenant and multi-setver Jenkins instances, as well as other architectures like Jenkinsfile Runner which is arguably "serverless". Breaking down a single term would be a good investment in future.

[Daniel Beck]

> On 14. Jun 2020, at 02:46, Mark Waite <mark.ea...@gmail.com> wrote:
>
> Using the word 'valet' instead of 'master' to refer to the node that executes inside the original Jenkins Java process. Replace it with the term you prefer
> • Redirect requests from /computer/(master)/ to /computer/(valet)/

Good idea.

> • Assign the label 'valet' to the node that executes inside the original Jenkins process

> • Assign the NODE_NAME="valet" env var to that node instead of NODE_NAME="master"
> • Replace 'master' with 'valet' in help-label.html for AbstractProject
> • Change display name of root node from 'master' to 'valet'
> • Change the Jenkins#getSelfLabel() to return the label atom of "valet" instead of "master"

> • Convert tests that reference agent labeled 'master' to use label 'valet'

Right, I assumed the basic 'change X to Y' was given and only listed things that needed doing on top of that. Good to have a complete list in advance though.

> Things that would not change:
> • The jenkins.security.Roles (internal concept only, not shown to users)

Interesting. While we could change the string used, the field is what's actually used, and then we're back to how much we want to break things. We may be able to attempt this one, but since everyone is just using the objectionably named *To*Callables anyway that we cannot really change.

> • Name of the key file in security/master.key (internal concept, not shown to users)

Is this the same kind of 'master' we're trying to get rid of? I haven't seen 'master key' having a historical association with slavery.

[Zbynek Konecny]

Hi Earl,

for blacklist/whitelist -- IMHO "blocked signatures" sounds more natural than "blocklist of signatures" or "denylist of signatures" -- maybe it's possible to change the wording to avoid these terms altogether, along the lines of https://github.com/rails/rails/pull/33681/files. If not, "safelist" also sounds like a reasonable replacement for "whitelist" (from https://english.stackexchange.com/a/51111).

Cheers,

Zbynek

[Justin Harringa]

Personally I thank the community for having already starting down this path.

I tend to like leader or controller from https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1 but I could also see server working. The difficulty I would see with primary/active is that folks who run Jenkins would have a bit of a conflict of terminology there.

Take care all.

[Antonio Muñiz]

In spanish the term "Master" ("Maestro"), when used in isolation (no "slave" in the context), has no negative connotations. Its main use is to describe someone very skilled in some matter (often used for artisans).

I might be suffering of language bias, just wanted to give some "non english native speaker" perspective to the conversation.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3411fed5-7e21-454a-b285-f719f07c1b3ao%40googlegroups.com.

--

* Antonio Manuel Muñiz
* amunizmartin.com
* amuniz...@gmail.com

[Angélique Jard]

My preference goes to "controller", "server" make me think somehow to the hardware physical machine. "Coordinator" is fine also (in the link tools.ietf in previous post) but a bit hard to pronounce.

As a non english native speaker (but french), I have some issue with "valet" and "majordomo" which have fix gender in french and are all male. I know that it's not like that in english but I think it's better to tell it now.

As a music player I also like "conductor" (as musical director) this is how I see my Jenkins instance when I use it, that orchestrate agents, Jenkinsfile could be the music sheet :) ....

[Matt Sicker]

A master key is a particular type of universal key used for unlocking
multiple different locks. In this case, the master key in Jenkins is
used to unlock all the other encrypted data. It sort of makes sense.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56742697-234e-4d29-b613-fcc13d072ed7n%40googlegroups.com.

[Markus Winter]

I think currently we use the term master for 2 different things.
First we have Jenkins orchestrating the builds, here the term controller
probably fits best but also server seems to fit for me
Second the server is also just plain agent (more or less). For this we
could use the term "main"  as the default label.

[Daniel Beck]

> On 15. Jun 2020, at 16:00, Antonio Muñiz <amuniz...@gmail.com> wrote:
>
> In spanish the term "Master" ("Maestro"), when used in isolation (no
> "slave" in the context), has no negative connotations.

If Jenkins (and before it, Hudson) had always used Master/Agent terminology, that would apply. But it didn't. I think it makes sense for us to do more than the bare minimum here.

It's bad enough that the internals are riddled with master/slave references probably indefinitely or we're going to break all the plugins, so it's not like there's a clean cut from obsolete terminology either.