Terminology Updates

1472 views
Skip to first unread message

Slide

unread,
Jun 11, 2020, 11:34:58 PM6/11/20
to jenkin...@googlegroups.com

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



--

Marky Jackson

unread,
Jun 11, 2020, 11:52:20 PM6/11/20
to jenkin...@googlegroups.com
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

unread,
Jun 12, 2020, 12:02:46 AM6/12/20
to jenkin...@googlegroups.com
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

unread,
Jun 12, 2020, 12:04:45 AM6/12/20
to Richard Bywater, jenkin...@googlegroups.com
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

unread,
Jun 12, 2020, 12:35:48 AM6/12/20
to jenkin...@googlegroups.com
Good point. I actually wonder if Manager is a reasonable replacement?

Marky Jackson

unread,
Jun 12, 2020, 12:42:34 AM6/12/20
to jenkin...@googlegroups.com
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.

Oleg Nenashev

unread,
Jun 12, 2020, 5:20:50 AM6/12/20
to Jenkins Developers
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

unread,
Jun 12, 2020, 12:13:35 PM6/12/20
to jenkin...@googlegroups.com

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

unread,
Jun 12, 2020, 1:05:26 PM6/12/20
to Jenkins Developers
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


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


Mark Waite

unread,
Jun 12, 2020, 1:21:32 PM6/12/20
to jenkinsci-dev
My favorite is Jenkins server.  I'll use whatever term is ultimately selected, but "Jenkins server" is easier for me than "Control Plane".

Vlad Silverman

unread,
Jun 12, 2020, 1:37:45 PM6/12/20
to jenkin...@googlegroups.com
I agree, “Jenkins Server” reflects primary functionality and definitely makes sense.

Thx, Vlad

Matt Sicker

unread,
Jun 12, 2020, 1:42:17 PM6/12/20
to jenkin...@googlegroups.com
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

unread,
Jun 12, 2020, 1:43:55 PM6/12/20
to jenkin...@googlegroups.com
signature.asc

Slide

unread,
Jun 12, 2020, 2:06:02 PM6/12/20
to Jenkins Developer List
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.

Jeff

unread,
Jun 12, 2020, 3:38:54 PM6/12/20
to jenkin...@googlegroups.com

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.

Richard Bywater

unread,
Jun 12, 2020, 7:36:51 PM6/12/20
to jenkin...@googlegroups.com
> 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.

Mez Pahlan

unread,
Jun 13, 2020, 4:01:23 AM6/13/20
to Jenkins Developers
Why not extend the butler analogy? Majordomo. Or MD for short?

Arnaud Héritier

unread,
Jun 13, 2020, 4:45:43 AM6/13/20
to jenkin...@googlegroups.com
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.
--
-----
Arnaud Héritier
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Daniel Beck

unread,
Jun 13, 2020, 5:02:01 AM6/13/20
to Jenkins Developers


> 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

unread,
Jun 13, 2020, 3:19:47 PM6/13/20
to Jenkins Developers
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

unread,
Jun 13, 2020, 4:25:56 PM6/13/20
to jenkinsci-dev
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.

James Nord

unread,
Jun 13, 2020, 5:04:50 PM6/13/20
to Jenkins Developers
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

unread,
Jun 13, 2020, 5:18:29 PM6/13/20
to jenkinsci-dev
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

unread,
Jun 13, 2020, 5:47:49 PM6/13/20
to jenkin...@googlegroups.com
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.


--

Ben Castellucci

unread,
Jun 13, 2020, 6:16:28 PM6/13/20
to Jenkins Developers
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

Mark Waite

unread,
Jun 13, 2020, 8:47:14 PM6/13/20
to jenkinsci-dev
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.

Oleg Nenashev

unread,
Jun 14, 2020, 5:56:20 AM6/14/20
to Jenkins Developers
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

unread,
Jun 14, 2020, 10:17:44 AM6/14/20
to Jenkins Developers


> 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

unread,
Jun 14, 2020, 7:25:02 PM6/14/20
to Jenkins Developers
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

unread,
Jun 15, 2020, 1:56:10 AM6/15/20
to Jenkins Developers
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

unread,
Jun 15, 2020, 10:00:27 AM6/15/20
to jenkin...@googlegroups.com
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.


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

Angélique Jard

unread,
Jun 15, 2020, 11:03:54 AM6/15/20
to Jenkins Developers
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

unread,
Jun 15, 2020, 11:18:21 AM6/15/20
to jenkin...@googlegroups.com
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

unread,
Jun 15, 2020, 4:39:54 PM6/15/20
to jenkin...@googlegroups.com
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

unread,
Jun 15, 2020, 4:44:04 PM6/15/20
to Jenkins Developers

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

Daniel Beck

unread,
Jun 15, 2020, 4:47:22 PM6/15/20
to Jenkins Developers


> On 15. Jun 2020, at 22:39, Markus Winter <m_wi...@gmx.de> wrote:
>
> Second the server is also just plain agent (more or less). For this we
> could use the term "main" as the default label.

That's what I proposed earlier in the thread as well.

'main' seems reasonable, but still has the connotation that it's actually a good idea to use this node, when it rarely is.

Adrien Lecharpentier

unread,
Jun 15, 2020, 5:49:15 PM6/15/20
to Jenkins Developers
I have to say that the music parallel from Angelique seems nice and has a lot of sense in my opinion. 
And the Jenkins butler is not that far from a music orchestrator as well.

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

Julie Ng

unread,
Jun 16, 2020, 1:30:29 PM6/16/20
to Jenkins Developers
+1 to everyone who suggested separating out UI and avoiding master altogether, i.e. log into Jenkins Web UI

As for the deployable itself, my personal favorites are

- "orchestrator" as a safe choice
- "conductor" suggestion from Angélique. Maybe we can establish a new vocab for Jenkins/CI/CD, so Conductor is equated with Jenkins just as "controller" is equated with Kubernetes.

Cheers
Julie

Justin Harringa

unread,
Jun 16, 2020, 1:30:31 PM6/16/20
to jenkin...@googlegroups.com
Conductor is a cool suggestion!

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/CLR55wMZwZ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKwJSvwus_DLMT%3Dn2vxwpHya-Cn24qNRU%2B2bDbrKQBOyYL25yw%40mail.gmail.com.

Tracy Miranda

unread,
Jun 16, 2020, 4:05:58 PM6/16/20
to jenkin...@googlegroups.com
Good discussion on 'master' replacement - listening and learning

On the other terminology I vote allowlist/denylist.  
This is also consistent with other projects communities e.g. Rails/Kubernetes

Tracy


Tammy Fox

unread,
Jun 16, 2020, 6:30:26 PM6/16/20
to jenkin...@googlegroups.com
+1 for allowlist/denylist to be consistent with what other communities are using.

I have 3 suggestions to replace Master:

1. Director
2. Expeditor
3. Coordinator

Thoughts? I was thinking about what a Master does, and it seems similar to the Expeditor in a restaurant kitchen. The Master getting build requests and sending it to the individual build agents is similar to an Expeditor sending different items to the different food stations in a restaurant.

Cheers,
Tammy



--
Tammy Fox
Director of Technical Publications
CloudBees, Inc.

Antoine Musso

unread,
Jun 16, 2020, 6:30:38 PM6/16/20
to jenkin...@googlegroups.com
Hello,

"orchestrator" sounds to me like a container management system such as
Kubernetes and I find it a bit misleading as to what Jenkins is
achieving. As a non native english speaker, I also find the term
difficult to read or write.

I really like the musical analogy Angélique proposed with "conductor", I
guess "director" could be a straight forward term as well and might be
even more understandable for non musical/non native english speakers. ;)

--

Antoine "hashar" Musso


Tammy Fox

unread,
Jun 16, 2020, 6:30:47 PM6/16/20
to Jenkins Developers
+1 for allowlist/denylist to be consistent with what other communities are using.

I have 3 suggestions to replace Master:

1. Director
2. Expeditor
3. Coordinator

Thoughts? I was thinking about what a Master does, and it seems similar to the Expeditor in a restaurant kitchen. The Master getting build requests and sending it to the individual build agents is similar to an Expeditor sending different items to the different food stations in a restaurant.

Oleg Nenashev

unread,
Jun 17, 2020, 10:30:35 AM6/17/20
to Jenkins Developers

Tony Noble

unread,
Jun 22, 2020, 5:18:05 AM6/22/20
to jenkin...@googlegroups.com
Another vote for allowlist/denylist (or blocklist).

Controller/Agent is a sensible replacement for the master/slave paradigm and has the benefit of being self-describing.  I don't see that there should be any confusion between Jenkins controller and Kubernetes controller any more than there would be with any other type of controller.  "Server" should apply to the host, IMO.

Tony

Slide

unread,
Jun 24, 2020, 1:51:42 PM6/24/20
to jenkin...@googlegroups.com
Hi All,

We had a discussion about this in the Governance Meeting last week and came to the following decisions to move forward.

We have had several recommendations/ideas for replacing the term "master" with another term. Ideas such as host, server, controller and others. We could not come to a consensus in the Governance Meeting, so we propose that we set a deadline for suggestions from this thread, then the Governance Board will select 10 of the suggestions for a Condorcet Internet Voting Service vote (Mark Waite will be the technical lead on setting this up). The poll will be used as input for the Governance Board to make the final decision. I propose that we keep suggestions going in this thread until July 1st after which the Governance Board can select the 10 suggestions that will go into the vote.

We also realize that one term doesn't always meet the needs of the scope of the usage of the term. We are starting a discussion to update the glossary (https://www.jenkins.io/doc/book/glossary/) with recommended terms for different use cases (e.g., Jenkins Web Interface, Jenkins Server Application).

The discussion around "blacklist/whitelist" resulted in consensus that we definitely need to deprecate and replace these terms. The context in which these terms appear can require different replacements than just one specific set. Simple replacements for "blacklist/whitelist" would be "denylist/allowlist", but since context matters, we are not requiring one specific set of terms be used for replacement, just that "blacklist/whitelist" be replaced with acceptable terms. If you have questions about the acceptability of replacement terms, please ask in the developer mailing list.

Once we decide on a term replacement for "master" we would like to focus on user facing places first like docs, web interface, etc., but the goal is to replace everything over time. The same priorities exist for "blacklist/whitelist".

If you have not made suggestions and would like to, please reply to this email and I will collect the suggestions in the Google Doc (https://docs.google.com/document/d/1-8myIWOZZktR0HNtbFIiNA0RfDCvkfKKuNI0C3wcvbo/edit?ts=5eea6706#) that Oleg created.

Thanks!

Alex
Jenkins Governance Board Member

Thomas de Grenier de Latour

unread,
Jun 24, 2020, 6:50:06 PM6/24/20
to jenkin...@googlegroups.com
As a native French speaker too, I fear that "conductor" would be
difficult to translate in French. With its "musical director" meaning,
it would be "chef d'orchestre", which is so explicit that it leaves
little room for a figurative sense (and it's also really long). The word
"conducteur" exists in French, but not with this meaning (it's either an
electrical wire, or a car driver; none of which being a good analogy for
the work Jenkins does).

To stay in the same lexical field, I would rather go with "maestro" (a
skilled / well-known conductor), because this word would be understood
as-is at least by Italian (obviously), English, French, and Spanish
speakers (maybe German speakers too, maybe others). Plus, for people
used to the historical Jenkins terminology, it gives an etymological
hint that it is indeed the new word for "master", and not a
new/different concept.

Now, that being said, you can't go wrong with "controller" I think, so
it would have my preference too. I don't think the potential confusion
with k8s controllers is an issue (when writing about Jenkins deployment
on K8S, use "K8S controller" / "Jenkins controller" to avoid any
ambiguity). The word is so widely used in IT that we can assume most
languages already have a well established translation for it. In French,
it's "contrôleur" (fun fact: the most common meaning for "contrôleur",
outside of the IT field, is "bus/train conductor").

Anyway, I guess my point here is that picking the new terminology should
be done with i18n in mind. Maybe double-check with active i18n
contributors for the most spoken languages that they have no issue with
the candidate words, or something like that.

Thomas.
> * amunizmartin.com <http://amunizmartin.com>
> * amuniz...@gmail.com
>
> --
> 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
> <mailto:jenkinsci-de...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/56742697-234e-4d29-b613-fcc13d072ed7n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/56742697-234e-4d29-b613-fcc13d072ed7n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Michael Dunlap

unread,
Jun 25, 2020, 2:16:59 PM6/25/20
to Jenkins Developers
First, thank you for consdering changes in language. It's coming at a good time.

To replace master, what about "main"? If not, "orchestrator" or "director"?

I'd like to pile on with the other folks that AllowList and DenyList are descriptive and appropriate. I don't like "BlockList" because it isn't as related to Allow as Deny is. There's also plenty of precedent in other projects - see the Apache web server's routine use of Allow and Deny.

Blocklist is also too similar to Blacklist both in writing and audibly.

Jeff Thompson

unread,
Jun 25, 2020, 6:36:05 PM6/25/20
to jenkin...@googlegroups.com

"maestro" is problematic in our context because it's too similar to the word we're trying to replace. Because of our usage history, that's a bigger issue than it might be in other contexts. In English, though they may have nuanced common usages, they're both basically the same word. They just got to modern English via different paths. They both derive from the same Latin root. We would be better to select something noticeably different.

We should definitely keep i18n in mind in choosing a name.

Jeff

Ian W

unread,
Jun 30, 2020, 11:25:16 AM6/30/20
to Jenkins Developers

There is heightened sensitivity to the naming of things, the meaning behind them and the meaning read into them. I applaud the Jenkins community work to address these matters. I first encountered the master / slave terminology when I first tried to configure an IDE drive on a IBM PC clone. Then the context was "Master Controller" and "Slave Controller". Perhaps my youthful naiveté did not associate the full qualified terms  with racial imagery to which the lone words are ascribed. When I first saw the plain "Master / Slave" usage in Jenkins, I definitely made that negative association. If there exists more neutral terminology, I am all for it.

 

The same goes for BlackList / WhiteList. Absolutely support the AllowList / DenyList pairing in its place.

 

The transition to node/agent works well, and it is the executors that do the work.

So, what for "the master" ? Some disliked Orchestrator, Controller, Host, Server, all for legitimate reasons.

 

I see "the master" as having two contexts. There is the Administrative context (configuration, plugins etc.), that determine focus, capability, delegation. Then there's the context of those tasks that are necessary to execute "on the master".

 

An elegant parallel for the first would be "Executive". That's our Org's (or Jenkins') " Leadership" capability. That's how it works in my Org, with an Executive (at HQ), multiple satellite offices (Nodes/Agents) and then the workers (executors).

 

What about the tasks run on master? It's still executors doing the work, but its sounds like the job for a "Concierge" to coordinate and satisfy the needs of the clients and delegate as necessary. Our Org has a "Concierge" that functions similar to a Concierge at a hotel that most people would be familiar with, but in an office setting

 

My recommendation: refer to the "Host/Server" context as the "Executive",  replace the "master" usage context with "Concierge".


The terms and roles are well defined, should translate reasonably well or are understood as-is, have neutral connotations and are not used in other tools in the CI space that I am aware of.

 

Ian

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com <mailto:jenkinsci-dev+unsub...@googlegroups.com>.

Slide

unread,
Jun 30, 2020, 11:47:50 AM6/30/20
to jenkin...@googlegroups.com
Just a reminder, this is the last day that we will be accepting suggestions. If you have an opinion on terms, please comment.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com <mailto:jenkinsci-de...@googlegroups.com>.

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


--

James Nord

unread,
Jun 30, 2020, 4:06:29 PM6/30/20
to Jenkins Developers
how about monolith 🤔 for the 'master'

it may be modular in terms of plugins and architecture but it's not micro services.
whilst some parts (fingerprint storage, artifact storage) are pluggable we still have the one big thing.

other equally bizarre / useful suggestions include:

* comptroller
* orchestrator (may have already been suggested apologies if it has)
* sneer (it's the collective noun for butlers) it would be good if used for the master node to disuade stop people using it
* trustee
* 'legacy_unsafe' (for the master node/executor label)
* "M" (as in James bond, head of all the agents)
* case officer (handles agents)
* director (tells the agents what to do)
* "C" the head of MI6 (not "M" as the bond movie make you believe)


/James

Martin Schmude

unread,
Jul 10, 2020, 2:31:07 PM7/10/20
to Jenkins Developers
My proposals for "master":

  • central
  • main
Besides this I'm find with "Jenkins server" or simply "server".

Robert Sandell

unread,
Jul 15, 2020, 9:51:26 AM7/15/20
to Jenkins Developer List
Good suggestions overall so far, so I can't really contribute to more suggestions.

Just that Blocklist reminds me too much of Blockchain, so I want to add my veto to that term :)

/B

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


--
Robert Sandell
Senior Software Engineer
CloudBees, Inc.

Twitter: robert_sandell

Runxia Ye

unread,
Jul 17, 2020, 9:13:44 AM7/17/20
to Jenkins Developers
From the shortlisted options selected by the governance board, I see words that in many languages have both a male and a female variant. The "default" version implicitly implies the the "male" variant. I know we are already taking a lot of different aspects into account, so I want to bring to attention this implicit association/unconscious bias that we may be having when choosing some of these words.

Jeff Thompson

unread,
Jul 17, 2020, 1:07:00 PM7/17/20
to jenkin...@googlegroups.com
On 7/16/20 7:52 AM, Runxia Ye wrote:
From the shortlisted options selected by the governance board, I see words that in many languages have both a male and a female variant. The "default" version implicitly implies the the "male" variant. I know we are already taking a lot of different aspects into account, so I want to bring to attention this implicit association/unconscious bias that we may be having when choosing some of these words.

That's a good point. Do you happen to have any suggestions on how to deal with this issue? I know a little bit of Spanish and am familiar with gendered nouns there. I don't have any idea how people are addressing bias in these languages.

Jeff

runx...@gmail.com

unread,
Jul 22, 2020, 3:20:42 AM7/22/20
to Jenkins Developers
Unfortunately I don't know how others are dealing with this issue.  But I would cast my vote for one where I think the word is pretty gender neutral in all languages I know. 

Mark Waite

unread,
Jul 22, 2020, 1:05:11 PM7/22/20
to Jenkins Developers

The