I'm actually against updating the changelog. The changes to terminology were not done then, and by showing the old and the new, you show growth. I'm not a fan of rewriting history, even in git.
On Tue, May 18, 2021 at 8:59 PM Mark Waite <[email protected]> wrote: > I like the idea of updating changelogs where possible, though it may be > more complicated than pure text replacement, especially when a string is > used to describe something from the user interface. > > On Tue, May 18, 2021 at 7:21 AM Oleg Nenashev <[email protected]> > wrote: > >> My vote is for updating changelogs where possible. Less obsolete >> terminology entries we have, the better for everyone. Of course >> retrospectively changing things like whitelisted-classes.txt filename for >> JEP-200 is not an option. But it is fine to do it where you just have text >> or Web UI controls. For the latter ones we might need to cleanup >> documentation and changelogs in parallel with the updates of changelogs. >> >> (@Angélique: thanks :P) >> >> >> On Tue, May 18, 2021 at 2:59 PM Angélique Jard <[email protected]> >> wrote: >> >>> 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 a topic in the >>> Google Groups "Jenkins Developers" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/jenkinsci-dev/x5vdlJDvntw/unsubscribe. >>> To unsubscribe from this group and all its topics, 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 >>> <https://groups.google.com/d/msgid/jenkinsci-dev/ff3dbd9b-8f7d-476f-ad09-153d4435fb52n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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/CAPfivLBQ_MvAUyGKqA_bDN5bAdC%3D2YPUsz4apHrccNmZkaQvTw%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBQ_MvAUyGKqA_bDN5bAdC%3D2YPUsz4apHrccNmZkaQvTw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAO49JtEaCx2P5GsuRp0s78uLXa7M3V-V08ZD5vCdg0pAC5EeLA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEaCx2P5GsuRp0s78uLXa7M3V-V08ZD5vCdg0pAC5EeLA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAG%3D_DutAmwT7tjK%3Di6T908R8KgRU%3DVE3Roa8sqXdqYyzhGxyXA%40mail.gmail.com.
