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 <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ff3dbd9b-8f7d-476f-ad09-153d4435fb52n%40googlegroups.com.
