I think there was pretty broad concensus that - at least for the rpms namespace on src.fpo - the master branch should be renamed to "rawhide" instead of main, because that actually carries meaning in this context, instead of changing one generic term to another. Will this feedback be incorporated into the Proposal?

I already added to the change that for src.fedoraproject.org we will symref rawhide and main... if we want to prefer rawhide in our docs that should be fine as well as allowing people used to main to use that if they want.

Why would somebody be used to "main" if it has never been "main"? I don't get it. This sounds like "consistency for consistency's sake" to me :(

Pagure 5.12 will support doing branch aliases via API, so we should be able to do whatever as soon as we're ready. That said, I favor using rawhide instead of main because the former is more meaningful.

Why would somebody be used to "main" if it has never been "main"? I don't get it. This sounds like "consistency for consistency's sake" to me :(

Because github and many other places are moving to main... so if you are a developer that works in those spaces and start contributing to fedora you might well assume our development branch is 'main' ?

I prefer rawhide too for dist-git.

+1

Oh, I forgot to vote. I would prefer "rawhide" over "main", but my vote is still +1 and weak +1, respectively.

My +1 is with the proviso that Dist-Git default branch changes to rawhide. I have not seen a compelling reason to do something else.

It doesn't have to be either or. We can make a symref and have the best of both. Is there any reason not to just have the symref for main and rawhide?

I don't mind symrefs for main and master, but having the real branch be rawhide means that things that don't know what to do with symrefs will use rawhide branch name.

I don't mind symrefs for main and master, but having the real branch be rawhide means that things that don't know what to do with symrefs will use rawhide branch name.

I'm strongly against a symref to 'master'. Doing that basically defeats the purpose of this change.

I am not sure there is anything that doesn't know what to do with a symref? pagure can handle them, git client does. Is there something you are aware of that wouldn't ?

I wonder whether libgit2 handles them transparently, which would affect fedpkg via GitPython and python libgit2 bindings.

Since we're all over the place with this discussion, I'm adding this to the meeting agenda for tomorrow.

My personal opinion:

1. I think 'rawhide' is a much more descriptive choice. However, I've heard suggestions that this too may have negative cultural associations (such as with cultures that revere cows). That said, I don't want to get into a naming debate about what to call our development branch at this time; I think it's a distraction from solving the original problem around "master".

2. I think changing the name of the development branch to "main" creates more problems than it solves. The primary argument in favor of this name is that it would align to the emerging industry standard for the default git branch, which makes sense: many tools will be designed or adapted to assume the presence of a branch with this name. However, this also potentially borrows trouble from the future: suppose that Fedora decides to merge its dist-git with another distribution (CentOS Stream, for example). Now we have to determine which "main" branch keeps the name.

3. I don't like the idea of a symref between "main" and "rawhide". I would much prefer to see them remain as separate branches, with "main" containing just a README describing the branch structure.

4. I very much dislike the idea of a symref between "master" and "main" and/or "rawhide". While it would ease the transition by allowing other consumers to continue using the old name, the reality is that we would end up retaining this symlink forever, thus keeping the offensive name alive and usable.

Since we're all over the place with this discussion, I'm adding this to the meeting agenda for tomorrow.

I'm on PTO this week and a 7am meeting doesn't sound very restfull, but I can try and make it. ;(

My personal opinion:

1. I think 'rawhide' is a much more descriptive choice. However, I've heard suggestions that this too may have negative cultural associations (such as with cultures that revere cows). That said, I don't want to get into a naming debate about what to call our development branch at this time; I think it's a distraction from solving the original problem around "master".

Yeah, I think we all want to avoid a bikeshed naming discussion.

1. I think changing the name of the development branch to "main" creates more problems than it solves. The primary argument in favor of this name is that it would align to the emerging industry standard for the default git branch, which makes sense: many tools will be designed or adapted to assume the presence of a branch with this name. However, this also potentially borrows trouble from the future: suppose that Fedora decides to merge its dist-git with another distribution (CentOS Stream, for example). Now we have to determine which "main" branch keeps the name.

CentOS stream doesn't use 'main' or 'master'. It only uses the c* namespace (c8, c8-beta, etc)

1. I don't like the idea of a symref between "main" and "rawhide". I would much prefer to see them remain as separate branches, with "main" containing just a README describing the branch structure.

I'm not sure why thats better... checkout, get main, try and look at source and see a README, grumble, check out the rawhide branch. Or just 'checkout main' and done.

1. I very much dislike the idea of a symref between "master" and "main" and/or "rawhide". While it would ease the transition by allowing other consumers to continue using the old name, the reality is that we would end up retaining this symlink forever, thus keeping the offensive name alive and usable.

yep. I am in agreement with that.

+1 with using rawhide name.

I won't be able to make it to the meeting, so my summary of opinions and votes:

• I support renaming dist git rpms/ master branches to rawhide (+1) - it removes the problematic branch name and reduces confusion. Even if different namespaces choose to have "main" or "stable".
• I support new pagure.io repos to have "main" as default (+1).
• I support the "main is a symbolic ref to rawhide" to support the new industry standard default branch name (+1), but I don't support it the other way around (0) (in case we ever merge dist git with rocky linux or similar, it would be complicated/confusing).
• I am very much against the "main branch only has a README" idea (-1), as has been discussed on the mailing list (search for README, the exchange was between me, @mattdm and @vondruch) -- it creates more work to either maintain the content of that README, or automate that information (and automated information can be presented in a better form).
• I don't mind "master" being a backwards compatibility symbolic ref (for some time), but I understand and respect that the change owners don't want that (so, +1 either way).
• I'd like our dist git server (whatever that will be at the time) to error out with an actionable error message when people try to pull from or push to master (heck it can even warn for a while with the master-symbolic-ref if we decide to have it). However, I don't know how technically complex this is, so I won't say this is a MUST.

We discussed this during today's meeting: I made the following proposal, which we voted on:

Proposal: Approve Change proposal to rename branch names from "master" to "main", except in dist-git-like repositories with branches matching fedora releases, where "rawhide" is preferred. Where the new default branch will be "rawhide", create symbolic refs from "main" to "rawhide".

The votes cast were (+5, 0, -0), and seeing that @churchyard 's comment above aligns with this, his vote was counted as +1 as well, resulting in a (+6, 0, -0) vote tally.

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z36LGFF4VNPE23EWI2EW6CNNF72AIRSP/

I ack my vote.