-1

1) This is a major change not for the CPE alone, but for the entire community which has tons of automations, scripts and services.

2) Rename of a master branch just for the sake of rename is not worth it.

If we have a technical reason to restructure git branches in dist-git, or tags in Koji, then renaming can be part of that restructure.

Generally, moving forward we should consider naming things more carefully. We have more examples of this (things like copr, or ursine packages, and so on). Naming is hard, and we need to put effort in it.

But digging in the current or legacy things and renaming old pieces, without fixing anything is a waste of community resources. And it doesn't really solve anything.

3) I think there is no reason to interpret Git master branches in offensive way. It has different connotation, and instead of agreeing to extend the connotation to include slavery references, we should teach and promote the proper connotation so that it takes over any offensive one.

We have other means to promote and maintain our statement on inclusive and diverse community. We already doing that much better than many others by being the open and inclusive community.

We don't have to follow every trend and repeat mistakes and public stunts made by of others in this area.

-1 unless there is a technical reason for it.

But digging in the current or legacy things and renaming old pieces, without fixing anything is a waste of community resources. And it doesn't really solve anything.
3) I think there is no reason to interpret Git master branches in offensive way. It has different connotation, and instead of agreeing to extend the connotation to include slavery references, we should teach and promote the proper connotation so that it takes over any offensive one.
We have other means to promote and maintain our statement on inclusive and diverse community. We already doing that much better than many others by being the open and inclusive community.

Why is teaching and promoting another connotation a better use of community resources?
What is the better connotation and how does it work with Rawhide being the development branch but the stable releases being the master pieces of the development process?

I agree with the sentiment and there's a big +1 from me there.

I agree with the issues around technical change. It's a LOT of change which requires a lot of engineering.

There's a lot of work that needs to be done across a number of projects (pagure, dist-git, koji, fedpkg etc to name but a few) and the support for different main branches than master needs to be landed there first. I think there should be bugs reported against all of those to get the ability for those projects to support different main branches and links to those bugs linked here for easy reference.

The thing to remember here is that CPE is moving dist-git to completely different platform and that requires a lot of changes to all of the aforementioned tools and changes to all the scripts and related that @bookwar mentioned above. This is the perfect time and opportunity to make this change and given we have to touch all those tools for the gitlab change I think it's a reasonable request to do it at that intersection.

I feel the move to gitlab is the perfect time to enact this change as well so I feel it is certainly something to do as part of that project.

+1 from me

Jim Perrin and I were already talking about needing to rename the branch as part of the planned CentOS Stream / Fedora dist-git integration. That integration hasn't progressed for various reasons, but I still have hope for it. So all non-technical reasons aside, there's a good practical one as well.

I also think this makes a lot of sense from a nomenclature point of view, since our rawhide branch isn't actually "master" anything in any sense. Calling it "rawhide" would be more clear. As CPE is working on moving us to a new git forge, that's a perfect time to go ahead and do this.

This ticket was opened before I (re-)joined Council, but renaming to rawhide is the most practical and sensible option to me. rawhide is specific Fedora jargon for our in-development work and it makes a lot of sense to me from a nomenclature point of view too.

I suggest marking this ticket as blocked, like @pbrobinson suggested, until the GitLab migration work is more defined. Fedora is one of those rare examples in open source where changing a default git branch is ACTUALLY A LOT OF WORK! So, I think taking this gradually, and wrapping it into another bigger change, is an effective way to introduce this change.

Are we able to mark this ticket as depending on #320 and add a blocked label?

Till took this to FESCo and they told him to file a Change proposal. So I'd say we can close this, unless unless someone wants to own making sure that proposal gets submitted.

I think this ticket makes sense for the D&I Council rep to "own". I'm willing to do that too, but not without more info about where GitLab migration is. This way, I can figure out which Fedora release we are proposing this Change for. I don't think it will be F34. Maybe F35, F36?

This is now moving forward in https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main

This ticket can now be closed but it can't because it depends on #203 which is still open. Someone with the permissions for this needs to adjust this.