From what I remember, the dist-git "master" branch was not named "rawhide" when migrating to git because that was the default branch name in git. Since git seems to be moving away from this name (this is how I understand https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006091126540.482@ZVAVAG-DN14RQO.ybpnyqbznva/#r), this justification does not make sense anymore. Therefore I propose to migrate Fedora's dist-git repos to use "rawhide" instead of "master" in the future.
While I agree that "rawhide" is a much better name since it matches the corresponding releasever, I fear that there's probably dozens of places in code somewhere where "master" is assumed as the branch name for rawhide. We'd need to go through all those code bases to make sure nothing breaks :(
I was waiting for this ticket to appear :)
Myself I'm not really fan of changing master to something else, but whatever. As long as somebody is willing to do this, find all places where it is hardcoded and fix those, I would not be against.
master
Are you such person? :)
In case of dist-git, "rawhide" would be a lot more obvious. For the branch used to build packages for rawhide, "rawhide" is a better name than "master"!
Personally, I don't find master offensive since I always understood it more to being about "master/copy" not "master/slave", but I know that this distinction is not clear and that there are people who do find it offensive, and for good reasons. I think it'll be good to change this default branch name in git.
Myself I'm not really fan of changing master to something else, but whatever. As long as somebody is willing to do this, find all places where it is hardcoded and fix those, I would not be against. Are you such person? :)
Do you need to know who will do the work to approve this?
No, not at all. I mean just approving such change does not make much sense without having somebody to work on it, having some contingency plan and so on.
Do you need to know who will do the work to approve this? No, not at all. I mean just approving such change does not make much sense without having somebody to work on it, having some contingency plan and so on.
Many projects have open tickets for changes but are still looking for someone to help implementing them. Once this is approved, it is also more motivating to invest time into this or it could become a project for an intern.
Contingency plan would be to revert the changes and go back to the current naming.
What else would you like to know?
Also, FESCo could also approve this with certain conditions if necessary. Also, once there is a go, discussing a timeline with Infra/Releng/CPE would be still be happening since they are the gatekeepers for the actual changes.
Ticket #2115 is an example where FESCo provides direction without requiring a task force ready to do the necessary steps.
@till So, I've been thinking about this for a bit.
I think what you're asking for is at its core not a "technical / engineering" change, but a naming change (that's not driven by a technical requirement, but by a "community requirement", for lack of a better term), which will result in a need for small (?) technical changes in a number of projects.
As such, might the Council be a better place to decide on the general idea, and then FESCo can approve any actual engineering changes that come of it?
FESCo can approve the idea, but we certainly cannot approve "let's do this now" if we don't know the scope.
Is this about renaming "master" to "rawhide" or creating a new branch called "rawhide" for rawhide? Some branch somewhere will be the main one that everything else is branched from.
If we're going to make this change, I would actually like to see two different things happen:
Discontinue use of the master branch for rawhide builds and creating a distinct rawhide branch for those builds. I would like it if master tracked current stable Fedora (even though that is branched anyway...I'd like the tracking part to be automated based on FTBFS results, updates, etc).
Use a different name for 'master'. git may make this change anyway (or at least a build time option) and I recommend we adopt that new name. If upstream does not plan on making that change, adopting a well known new default name like what GitHub choose will make more sense to developers.
On the first point, using a separate branch specifically for rawhide gains us a number of advantages that make for an improved developer experience:
Do you need to know who will do the work to approve this? FESCo can approve the idea, but we certainly cannot approve "let's do this now" if we don't know the scope.
This works for me. I am fine with getting general approval and then starting to discuss a timeline.
So, let me toss into the mix: do we want to at the same time change the name 'rawhide' ?
I've seen a number of emails over the years from people who really don't like the connotations from that word. Of course that opens a naming bikeshed.
I'm not opposed to renaming 'master' personally.
Draft Action plan:
When branching for the next release: 1) Rename master to rawhide in all dist-git repos 2) Add a symlink using git symbolic-ref from master to rawhide 3) Fix all occurences in infra ansible/releng git from master to rawhide 4) Adjust PDC 5) Do the actual branching for fxy 6) Adjust fedpkg 7) Fix other tools that are not managed via infra ansible 8) At some point, remove the master to rawhide symlink, maybe add one for the new default branch name that Git will use (probably main)
7) Fix other tools that are not managed via infra ansible
This will be a major pain point. What are those? How do we find them?
7) Fix other tools that are not managed via infra ansible This will be a major pain point. What are those? How do we find them?
There will be plenty of announcements so that everyone has the chance to know about this and then the maintainers can fix this or speak up.
I suggest this goes through the System-Wide Change process to make sure it is well-communicated to the community.
+1
Draft Action plan: When branching for the next release:
So, this kind of implies the work is going to be done by infrastructure/releng then?
1) Rename master to rawhide in all dist-git repos
Will there be an outage for this? if someone pushes while moving or tries to build or something there might be problems.
2) Add a symlink using git symbolic-ref from master to rawhide 3) Fix all occurences in infra ansible/releng git from master to rawhide 4) Adjust PDC 5) Do the actual branching for fxy 6) Adjust fedpkg 7) Fix other tools that are not managed via infra ansible 8) At some point, remove the master to rawhide symlink, maybe add one for the new default branch name that Git will use (probably main)
Thats additional work on releng... would there be people to write scripts to do this, be around to help debug them, etc?
Draft Action plan: When branching for the next release: So, this kind of implies the work is going to be done by infrastructure/releng then?
At least they need to be involved, since they have the permissions to do the actual changes on dist-git/running Ansible. Timing this around branching would allow to have most time to update tools that need master/rawhide for a development process. A later time might also suffice.
1) Rename master to rawhide in all dist-git repos Will there be an outage for this? if someone pushes while moving or tries to build or something there might be problems.
From what I understand, building should not be a problem, since it uses the git hash and not the branch name. There will probably be a race condition that will make pushing to master fail if it happens after master was renamed but the link not being created, yet. It would probably also require some change to ensure that maintainers cannot re-create the master branch in the short time between renaming and symlinking (not sure, if this is currently possible or is restricted by dist-git.
2) Add a symlink using git symbolic-ref from master to rawhide 3) Fix all occurences in infra ansible/releng git from master to rawhide 4) Adjust PDC 5) Do the actual branching for fxy 6) Adjust fedpkg 7) Fix other tools that are not managed via infra ansible 8) At some point, remove the master to rawhide symlink, maybe add one for the new default branch name that Git will use (probably main) Thats additional work on releng... would there be people to write scripts to do this, be around to help debug them, etc?
There will be at least tasks such as reviewing/merging PRs and running scripts or playbooks for releng/infra. Once the general idea/direction is approved, I will see how to get the actual work done. Depending on the effort it could also be a hackfest with interested developers or a possible future internship for something like Outreachy.
2) Add a symlink using git symbolic-ref from master to rawhide
While I am generally in favor of eliminating these terms, I should point out that I don't think it's technologically feasible as you've proposed. git symbolic-ref is a client-side option, not a server-side one. It would still be required to manually change every client to use the new nomenclature.
git symbolic-ref
Unfortunately, I think we're in a bit of a bind here. We could do a mass-renaming of the master branches in dist-git, but the reality would be that we'd need to update a massive number of scripts and tools that assume the use of master.
2) Add a symlink using git symbolic-ref from master to rawhide While I am generally in favor of eliminating these terms, I should point out that I don't think it's technologically feasible as you've proposed. git symbolic-ref is a client-side option, not a server-side one. It would still be required to manually change every client to use the new nomenclature.
I am not sure what you mean. I tested this with creating one repo with the symlink and then cloned from it. When I push to "origin/master" from the clone, the changes appear both in master and in symlink in the origin repo. So it seems to work as intended. I guess the "clients" do not really care/know whether there are symlinks in the "server repo" or if those are two distinct branches.
2) Add a symlink using git symbolic-ref from master to rawhide While I am generally in favor of eliminating these terms, I should point out that I don't think it's technologically feasible as you've proposed. git symbolic-ref is a client-side option, not a server-side one. It would still be required to manually change every client to use the new nomenclature. I am not sure what you mean. I tested this with creating one repo with the symlink and then cloned from it. When I push to "origin/master" from the clone, the changes appear both in master and in symlink in the origin repo. So it seems to work as intended. I guess the "clients" do not really care/know whether there are symlinks in the "server repo" or if those are two distinct branches.
Could you list your exact steps? Because everything I've been able to locate suggests that what you're claiming isn't possible via the Git network protocol.
On fedorapeople.org:
cd public_git/ cd branch_test.git/ git init --bare .
Then clone to my system, add a commit and push
Now on fedorapeople:
git branch -m master rawhide git symbolic-ref refs/heads/rawhide refs/heads/master
Now I changed/pushed something to fedorapeople to master without a problem. When I fetched it also showed the rawhide branch with the changes from devel.
Huh... that does work. In direct contradiction to all the articles I found on the subject...
However, it does still have some problems. Namely that if we also try to change the default checkout to be rawhide instead of master with git symbolic-ref HEAD refs/heads/rawhide and then clone it freshly, we still end up with master as the default, as well as a warning in git remote show origin:
rawhide
git symbolic-ref HEAD refs/heads/rawhide
git remote show origin
* remote origin Fetch URL: sgallagh@fedorapeople.org:public_git/alias.git Push URL: sgallagh@fedorapeople.org:public_git/alias.git HEAD branch (remote HEAD is ambiguous, may be one of the following): master rawhide Remote branches: master tracked rawhide tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date)
Huh... that does work. In direct contradiction to all the articles I found on the subject... However, it does still have some problems. Namely that if we also try to change the default checkout to be rawhide instead of master with git symbolic-ref HEAD refs/heads/rawhide and then clone it freshly, we still end up with master as the default, as well as a warning in git remote
I see. I guess this means that it will only be fully completed by removing the link again and asking users to updated their working-copy if they do not use fedpkg, which could migrate everything automatically.
Nevertheless, since it was also possible to migrate from CVS to git, it should somehow be possible to migrate away from master to rawhide (or something else). In case we can also rename Fedora Rawhide to Fedora Main, I hope that future git would prefer main over rawhide as the default branch.
+1 for replacing master, I also think that this might be a good opportunity to replace rawhide by something more explicit like next or develop or something else :smile:
next
develop
I think "rawhide" has enormous "brand recognition". If you say "this is the rawhide branch", or "I'm developing for rawhide" or any other variation, every packager in Fedora and a lot of people outside of Fedora will know exactly what you are talking about. In contrast, statements like "this is the next branch", and "I'm developing for the develop branch" would need to be qualified with context every time.
I am 100% in favor of moving master -> rawhide. I am 100% not in favor of repurposing master for some weird other purpose (tracking latest stable, munging it for some other purpose, etc.).
If we ever execute on the Grand Vision :tm: of pulling different distro Dist-Git systems into one repo where we can compare different distros' packaging and allow cherry-picking freely, it'd be great if nobody's refs collided. :100:
Since the general response seems to be positive, therefore to make this formal, here is an idea for a proposal. It would be great if someone from FESCo could use this or a similar one to move voting forward according to https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy
PROPOSAL: FESCo supports renaming the dist-git "master" branch to "rawhide" or a different name in case Fedora Rawhide will be renamed. To ensure all stakeholders are properly notified and to figure out the details, FESCo requests a System Wide Change Proposal to be submitted.
Since the deadline for System Wide Change Proposal is in a week, it would be great to have an agreement that this should be the next step beforehand.
As much as I am in favor of retiring the term master, I'm -1 on making this change in Fedora for the sole reason that the work necessary to change branches everywhere that might be expecting master is fairly enormous.
Heck, I tried to make this change for my libmodulemd upstream and that apparently broke the Yocto project's builds. I cannot even fathom how many things would break if the Rawhide branch changed.
libmodulemd
I wonder if it would be better to push for this in git upstream instead. It might be more feasible to convince git upstream to do s/^master$/main/g on all ref-handling.
s/^master$/main/g
Can we please totally leave "renaming rawhide to something else" out of this?
Yes, please.
PROPOSAL: FESCo supports renaming the dist-git "master" branch to "rawhide"
... or something else
-1
To answers @sgallagh's concern:
the work necessary to change branches everywhere that might be expecting master is fairly enormous.
No disagreement with the amount of work. But we can still support the idea, and explore the exact steps and the amount of work, without committing to do it. With a System Wide Change proposal we could start figuring out if we can actually pull it off.
So why do we acknowledge people being uncomfortable with master but not people being uncomfortable with connotation associated with rawhide ? that seems weird to me.
Anyway I don't have a strong opinion on that so I am happy to be outvoted :smile:
If there is a good reason to rename Rawhide, then it is a separate discussion and it does not really matter for the discussion in this ticket since whether "master" is renamed to "rawhide" or "next" should be the same amount of work.
What is the connotation? Maybe it is not so clear, for example https://en.wikipedia.org/wiki/Rawhide does not make it clear to me that it is a problematic name.
From that Wikipedia link "Wet rawhide has been used by some earlier cultures as a means of torture or execution, gradually biting into or squeezing the flesh of body parts it encloses as it dries"
If there is a good reason to rename Rawhide, then it is a separate discussion and it does not really matter for the discussion in this ticket since whether "master" is renamed to "rawhide" or "next" should be the same amount of work. Agreed that these are separate issues that should be considered separately by FESCo. However I will note there's an ordering issue: if we change master to rawhide and then change rawhide's name, we have to do the work (and cause confusion) twice.
Agreed that these are separate issues that should be considered separately by FESCo. However I will note there's an ordering issue: if we change master to rawhide and then change rawhide's name, we have to do the work (and cause confusion) twice.
It may be better to decide if we're going to change rawhide first. If the answer is no, then there's nothing blocking consideration of this ticket. If the answer is yes, then it might be worth putting this ticket on hold until a rename is settled (acknowledging, of course, that renaming rawhide will not be a short or controversy-free process).
So why do we acknowledge people being uncomfortable with master but not people being uncomfortable with connotation associated with rawhide ? that seems weird to me. What is the connotation? Maybe it is not so clear, for example https://en.wikipedia.org/wiki/Rawhide does not make it clear to me that it is a problematic name.
I can try and find emails if folks want, but from what I recall:
I realize rawhide has a long history, but it also has baggage... some people think of it as always not working and unrunable still. Sorry to muddy things here, but I did want to collapse 2 big changes into 1 if we are doing them both.
Once there is a general go for this ticket, one possible task is to update all tools/scripts to query one central place for the branch name for Rawhide/the Fedora development release. This can still move forward. Only doing the actual rename would be blocked by knowing the name.
As for "who will do this?" — I'm happy to add this to our official requests for projects for Red Hat's CPE, either as part of the overall dist-git forge change or on its own.
Honestly, while I fully support the intention (about renaming master, not about renaming rawhide), if Fedora has a way to do official requests for projects for Red Hat's CPE, I'd rather see https://pagure.io/fesco/issue/2115 finished.
Why? Using it for project-specific non-branch specific files is a much better purpose.
If we ever execute on the Grand Vision ™ of pulling different distro Dist-Git systems into one repo where we can compare different distros' packaging and allow cherry-picking freely, it'd be great if nobody's refs collided. 💯
I can't see that ever happening. :)
I am 100% in favor of moving master -> rawhide. I am 100% not in favor of repurposing master for some weird other purpose (tracking latest stable, munging it for some other purpose, etc.). Why? Using it for project-specific non-branch specific files is a much better purpose.
Then a epel, fedora or centos branch seems to be more descriptive. Not sure what would be Fedora or CenOS specific that should be tracked in special/non-release branch.
This seems to have stalled. What is needed to get this moving?
Do a proposal that people can vote on and/or submit this as a Fedora change proposal.
Personally for me:
Personally for me: I wouldn't support renaming this until it is scoped and volunteered (who does what).
I wouldn't support renaming this until it is scoped and volunteered (who does what).
Since it is a rather simple change and it is only a problem because it might be hardcoded at too many places, this is candidate for a internship project. Part of this would be to figure out which places need to be changed. But without support for the direction, it would be rather disappointing for an intern to start with this but then get this declined.
I might support some kind of statement that says that if somebody does (1), fesco will support it, but I'd rather see (1) first.
This would be great. Here is my proposal from before:
I see only one explict vote for this, yet.
I don't like discussing things solely in fesco tickets, this needs wider community participation (but I suspect it will be bikeshedding and/or flame).
Sure, are there any specific questions you would like to get answered or just some opinions about this?
I juts don't like to decide this hidden in our ticket tracker and then just announce the decision. Decisions should be made and discussed in the open.
Sure, are there any specific questions you would like to get answered or just some opinions about this? I juts don't like to decide this hidden in our ticket tracker and then just announce the decision. Decisions should be made and discussed in the open.
I sent an e-mail to fedora devel. It seems to be useful to notifications for new FESCo tickets to the list if filing tickets here is considered to be hidden. Then it does not need an extra, manual step. Filed #2430 for this.
A further note on the resourcing issue... since this was filed, Red Hat's CTO released this statement: https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language
I think we can count on getting the help we need to implement, and it is a Red Hat priority.
Just had another idea, how about instead of branch down from the rawhide branch to new branched to make Rawhide always use the fxy version that it develops. So instead of creating branched f33 later we would rename master to f33 now and then once we need to branch we branch of Rawhide as f34? There could still be a symbolic ref called rawhide for the latest rawhide for convenience. What do you think?
Bring that idea to the devel thread please.
sent a copy to the devel list.
It has been nearly three weeks since my e-mail to the devel list. What is now necessary to move this forward?
Make an F34 System Wide Change proposal for switching the development branch name from master to rawhide.
It has been nearly three weeks since my e-mail to the devel list. What is now necessary to move this forward? Make an F34 System Wide Change proposal for switching the development branch name from master to rawhide.
So, does this mean that FESCo accepts my proposal from https://pagure.io/fesco/issue/2410#comment-663871 ?
It would be great to get a clear statement about this from FESCo.
Also, why would it be a Fedora 34 Change? There were some suggestions to align it with the switch to Gitlab - is this planned for Fedora 34?
Uh ... so you want us to approve the action that will result in us having to approve virtually the same thing again? That seems like twice the work for no gain to me :confused:
I highly doubt it. The only public "progress" on the GitLab investigation I can find is the GitLab ticket where pretty much nothing has happened in two months. The Forge stuff isn't even mentioned in the CPE weekly reports anymore, as it looks like it was dropped from their Q3 priorities. I'd rather not have the master → rawhide (whatever name) branch renaming not be tied to a GitLab transition.
PROPOSAL: FESCo supports renaming the dist-git "master" branch to "rawhide" or a different name in case Fedora Rawhide will be renamed. To ensure all stakeholders are properly notified and to figure out the details, FESCo requests a System Wide Change Proposal to be submitted. Uh ... so you want us to approve the action that will result in us having to approve virtually the same thing again? That seems like twice the work for no gain to me :confused:
The actual System Wide Change Proposal would be a lot more detailed, I think this was discussed in this ticket already.
Also, why would it be a Fedora 34 Change? There were some suggestions to align it with the switch to Gitlab - is this planned for Fedora 34? I highly doubt it. The only public "progress" on the GitLab investigation I can find is the GitLab ticket where pretty much nothing has happened in two months. The Forge stuff isn't even mentioned in the CPE weekly reports anymore, as it looks like it was dropped from their Q3 priorities. I'd rather not have the master → rawhide (whatever name) branch renaming not be tied to a GitLab transition.
So if it is not happening for F34, it does not make sense to do a change proposal for this release. However, those are IMHO details that can be figured out once the idea is approved in general.
Also, I have to say I am disappointed in the way I (do not) get real feedback here.
https://pagure.io/fesco/issue/2410#comment-659371 stated that FESCo could approve my proposal and there was no objection.
https://pagure.io/fesco/issue/2410#comment-663812 stated again, that I can send a proposal and then people would vote without any objection
In https://pagure.io/fesco/issue/2410#comment-664127 I was asked to create a thread on the devel list which I did and still no movement, here.
This does not really match the ticket policy that states that there would be a decision in the ticket or in a meeting: https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy
So, we discussed this at a recent / few weeks ago releng meeting, because we got a request to rename the master branch for flatpaks.
I meant to reach out to you/here but got swamped and haven't done so until now.
We (releng in this case) thought that this was something we should do/work on, but we thought it was too much more to do around branching, so we thought about a phased approach.
Do some things soonish (like flatpaks) and some smaller repos we use to work out issues and pain points, then after f34 release we look at doing this for dist-git and the 'bigger' repos where we have a lot of contributors in some sort of flag day. That would leave lots of time for people to adjust checkouts and learn of the change, etc.
I think making a f34 change out of it might be good (even though we would hope to get most of it done very early in the f34 cycle). I would be happy to work with you on such a change if you are ok with the above approach?
As for approval, I'd prefer we go through the change process and just approve it as a f34 change.
Metadata Update from @dcantrell: - Issue tagged with: meeting
From today's FESCo meeting we agree to close this ticket and wait for a formal change proposal on this topic.
Metadata Update from @dcantrell: - Issue close_status updated to: Rejected - Issue status updated to: Closed (was: Open)
This was implemented in Fedora's dist-git: https://twitter.com/spotfoss/status/1357079832161583104
This was implemented in Fedora's dist-git:
Mostly, it's not fully finished yet: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/63ZZMPQCOKDUOWVGSOIQ5WXA75GJJYSH/
Thanks for the update @pingou, I couldn't find an issue to follow so I could get updates on the process.
Log in to comment on this ticket.