RFC: Rename 'master' branches to 'main'
kajatiger opened this issue · comments
Proposal:
Rename master branches to main.
Reasoning
- The naming "master" does not describe, what that branch actually does and "main" seems to be much more fitting.
- Historically the naming comes from the "master-slave" term, a painful analogy unwisely chosen for technical relationships that do not reflect the actual meaning of the analogy and has a bitter sound to it that can cause a distraction at work.
- Verbal gestures can have a lot more impact on our subconciousness than you would first think. There are a lot of scientific studies in that field that show that words have a huge impact on how we see the world (there are languages without any concepts of "left" and "right" or without concept of the past and studies with speakers of that languages for example).
- Every other name in our codebase is very carefully chosen -> It would be consistent to carefully choose branch names as well.
- Making the change is possible and does not harm anyone.
- Github and other tools (e.g. OhMyZSh) are supporting the alternative "main".
Exceptions:
I don't think we should make any exceptions, but rather see this as a gradual process where we start with the branch easiest to rename and work our way forwards to the more tricky cases.
Additional Context:
Read what Github has to say here.
How is this RFC resolved?
- Write a guide/plan what repo to start with and how and how to continue.
- Start with the easiest repo to change (e.g. README) and revisit plan to make adjustments from learnings.
- Continue and repeat with the next easiest repo.
It is time 👍
Also found this in our jenkins cook book repo description. A better wording could be part of the change.
And it looks like the naming within the repository is also followed through:
https://github.com/artsy/jenkins-cookbooks/search?q=slave
Very supportive of this. It was mentioned somewhere on slack, we discussed this a few months ago. We were strongly in favor of adopting new names and we were waiting for Github to provide better tooling.
Given the renewed momentum, I'd encourage us to put together a clear incremental plan to make this happen so that we don't get stuck here.
Thanks a lot @kajatiger for reopening this thread! I'm glad you're pushing this forward, it's an important initiative. 🙏
I started drafting a PR with a guide documentation listing the more independent repos that would be easier to start with: https://github.com/artsy/README/pull/387/files
My only concerns would be technical ones to be aware of in CI - Hokusai checks that you are on master in certain places as a safeguard before running updates to kubernetes specs so we will have to roll out a change here in parallel
As far as Jenkins goes we don't have control over the nomenclature of the plugin as we don't develop it but are moving away from EC2 AMI "build slaves" in general.
Definitely it would be helpful to have in that playbook/plan-to-resolve-this-RFC some instructions for devs that have the repos cloned (maybe forked too? even thought that's not our jam anymore.), and to plan the CI changes first, to support both master and main, then do any renaming.
Process is on the move, very slow move, but moving 🐌
@kajatiger When you have a moment, it might be nice to update this thread with our RFC resolution template.
Resolution
We decided to do it. Most of the engineering team was silent, the only voices came from supporters.
Level of Support
2: Positive feedback.
Additional Context:
While a lot of people seem happy with the decision, not so many have implemented it yet. We need to promote the practical work more across the teams.
Next Steps
We will implement it everywhere (already started on some projects).
Exceptions
There are no exceptions, there could be tricky cases where it takes a bit longer to implement the renaiming.