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
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.
--
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F2B3AC63-DD98-48A4-A5F2-064D9336C1BD%40gmail.com.
My vote:
--
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.
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.
--
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.
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.
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.
--
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.
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...
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)
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfc0kdVi_RDiKp4RATipbwPBAMYo%3Df20PoNhaMSw%2B5Y5w%40mail.gmail.com.
> 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.
- …?
--
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.
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.
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.
--
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.
--
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/300611FD-062F-40B8-9292-8E16170ABDE6%40beckweb.net.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAOa798WubmTKAqcV_bKtN0jSVUKNV%3DaSxfhybqPcSP%3D8tqHynA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6peQaXhFNq1qs_r4imw2Wd3Y5X4Nb5rLabZ4mLtZs%2B8pg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a12075ca-48e0-4c55-bc8b-0eee84a210d3o%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9HVDofkU0d3r8ZJvVoicsh13AX3ys2r-CKA2W3DdmXpOA%40mail.gmail.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
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>.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8a178366-de57-4375-aa48-7e706ca8ca87o%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9c289226-7882-4c9d-a816-6e813ef9c7b4n%40googlegroups.com.
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
The Jenkins terminology poll for the “master” term replacement is open at https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_1bd92a17371a1ca5&akey=f82b79a50f54ad87 . We would appreciate your votes! If you are interested to participate, please submit your choice by July 29, 14:00 PM UTC.
Thanks,
Mark Waite
--
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/b8487054-6383-4dec-be3e-29103215cc09o%40googlegroups.com.
Unfortunately, new terms can't be included in the the votiing. The voting is already in progress at https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_1bd92a17371a1ca5&akey=f82b79a50f54ad87 . The governance board is using the voting as input for the final decision on the term to be used.
On Thu, Jul 23, 2020 at 7:15 AM Steve Carter <swe...@gmail.com> wrote:
Hi all,
I showed up late to the party, so I'll accept a snub gracefully, but I was intrigued by the problem of replacing the term "master" and have one further term I would like to put in the poll if at all possible.
Dispatcher.
This would most correctly apply to the function of taking jobs off the queue and handing them to nodes. What we today know as master would therefore consist of dispatcher and zero-or-one agents.
What I think distinguishes this suggestion is that it connotes a service provided to agents in collaboration rather than a hierarchical power relationship.
--
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.