Hello, what do you think about changing terminology in changelogs ? The topic has been raised on Jira comment here: https://issues.jenkins.io/browse/JENKINS-65398?focusedCommentId=408976&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-408976
I was not doing it because changing the past didn't seems accurate, but I don't have a strong opinion, I would say "why not". Does anyone has some opinion on that ? (@Oleg: I love that board by the way :D ) On Monday, May 17, 2021 at 11:51:06 PM UTC+2 Oleg Nenashev wrote: > Do we have any terms we'd like to finalize during the next meeting? > I have also created https://github.com/orgs/jenkinsci/projects/5 to track > the related pull requests and to see where any help is needed > > On Thursday, May 6, 2021 at 10:12:31 AM UTC+2 Oleg Nenashev wrote: > >> Hi all, >> >> We made decisions on a few terms at the yesterday's governance meeting: >> >> >> >> - Master node => "Built-in Node" >> >> >> - "master" label => "built-in" // We will use it unless we discover a >> technical issue with the hyphen. Then we fallback to “builtin” >> >> >> - “Master branch” in documentation and help => "default branch" >> - Agent-to-Master security => " Agent-to-Controller security " >> - "Jenkins master container " => "Jenkins controller container" >> >> >> - "Serialization whitelist" for JEP-200 => "serialization allowlist" >> >> We also agreed that we will be using "allowlist" in our terminology, not >> the "permitlist" as it was suggested in a few occasions. We have not >> finalized decisions on other terms, including the "Jenkins master pod". I >> raised https://github.com/jenkinsci/kubernetes-operator/issues/561 in >> the Jenkins operator project to track the change on its side once we agree >> on the term. >> >> If anyone is interested, I can create a global "terminology cleanup" >> project in the jenkinsci organization. It will allow tracking pull request >> better on the GitHub's side >> >> Best regards, >> Oleg Nenashev >> >> >> On Wednesday, May 5, 2021 at 12:02:42 PM UTC+2 Daniel Beck wrote: >> >>> >>> >>> > On 4. May 2021, at 16:59, Oleg Nenashev <o.v.ne...@gmail.com> wrote: >>> > >>> > • Master node => "Built-in Node" >>> >>> To provide a bit of context for this one for those that don't remember >>> from last year :-) >>> >>> Before, there was no real distinction between "Jenkins master, the >>> process" (mostly) and "Jenkins master, the node". When I worked on the PR >>> in which I started cleaning up the terms, it became apparent a different >>> term could be useful.[1] >>> >>> A simple example: The built-in node can be offline while the controller >>> is otherwise running. >>> >>> In some code, the relation between master-specific and global node >>> properties also wasn't clear in some places because both were occasionally >>> called "master" (and only one set is inherited by agents). >>> >>> There's not a huge list of obvious examples because a lot of the things >>> that could matter are shared (process, file system, config file to an >>> extent) or irrelevant (node launcher). >>> >>> I still think it would be useful to distinguish in terms between the >>> controller and the built-in node, if only because 'controller' for the node >>> may create wrong associations (it controlling things, rather than "just" >>> being part of the controller process). >>> >>> >>> However there are also limitations, which make a different term not an >>> obviously correct choice: >>> >>> - The built-in node is part of the controller process, it shares the >>> controller's file system and OS permissions. If the built-in node is doing >>> work, the controller has load. A lot of resources are shared, so "the >>> built-in node's configuration is stored in the config.xml file with most of >>> the controller configuration on the controller file system" etc. >>> - People seem to confuse executors and nodes/agents fairly regularly, so >>> may well consider these to be the same thing because the differences are >>> way less relevant than compared to agents, leading to wrong documentation >>> and other advice, possibly confusing those aware of the terms. (It might >>> help that controller as a term is getting rather well established, and that >>> the node will get labels (both UI and environment var) referring to it by >>> its new name, but who knows.) >>> >>> >>> I encourage you to check out the PR with placeholder term to get a sense >>> for the differences and consider whether you think distinguishing the terms >>> is useful. As the PR is still a draft and uses an obvious placeholder term, >>> please skip doing an actual review for now. >>> >>> (Note that the behavior-changing code in my PR (related to migration) >>> would be needed anyway, regardless of the term we choose. It's more about >>> removing "master" than what the replacement term is.) >>> >>> >>> 1: https://github.com/jenkinsci/jenkins/pull/5425 >>> >>> -- 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-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ff3dbd9b-8f7d-476f-ad09-153d4435fb52n%40googlegroups.com.
