Planning for the Forgejo distgit migration #3623

Open
opened 2026-06-23 00:37:38 +00:00 by gotmax23 · 18 comments
Owner

There was some discussion in the FRCL Matrix room with @decathorpe, @blc, and I about how FESCo should be involved with the Forgejo distgit migration. I was asked to officially bring up the subject, so here's a ticket.

The main idea of the discussion was creating opportunities for more regular, granular communication/feedback between FESCo (and the overall packager community, I think) and the Forge initiative in addition to a high-level Change Proposal for the final migration that other infra migrations have had in the past.
Also, I think we should agree in advance on some soft requirements for the migration so we have the same idea of what the main priorities/blockers are for the migration as the work is ongoing.

I'm very open to ideas about how this should look. To start, I think it makes sense to put this on a FESCo meeting agenda and invite the relevant folks to discuss.

There was [some discussion in the FRCL Matrix room] with @decathorpe, @blc, and I about how FESCo should be involved with the Forgejo distgit migration. I was asked to officially bring up the subject, so here's a ticket. The main idea of the discussion was creating opportunities for more regular, granular communication/feedback between FESCo (and the overall packager community, I think) and the Forge initiative in addition to a high-level Change Proposal for the final migration that other infra migrations have had in the past. Also, I think we should agree in advance on some soft requirements for the migration so we have the same idea of what the main priorities/blockers are for the migration as the work is ongoing. I'm very open to ideas about how this should look. To start, I think it makes sense to put this on a FESCo meeting agenda and invite the relevant folks to discuss. [some discussion in the FRCL Matrix room]: https://matrix.to/#/!jiRCoLQaTIfefGfGRr:fedora.im/$iRvanOCK_u20yqWGBotxyqZiM_C3pPKPTrsBdGFp1OQ?via=fedora.im&via=matrix.org&via=fedoraproject.org
Author
Owner

Metadata Update from @gotmax23:

  • Issue tagged with: meeting
**Metadata Update from @gotmax23**: - Issue tagged with: meeting
Author
Owner

INFO: we will wait to hear from the Forge team and postpone this ticket until next week

(meeting log discussion starts at 17:15:32)

INFO: we will wait to hear from the Forge team and postpone this ticket until next week ([meeting log](https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-06-30/fesco.2026-06-30-17.01.log.html) discussion starts at 17:15:32)
Owner
CC: @humaton @ryanlerch

Thanks for opening the ticket and bringing this up. It’s great to get FESCo involved on the distgit/src.fp.o migration. As we wrap up the Pagure.io shutdown, the timing is perfect to start aligning on the next phase.

@humaton is currently working on the requirements, and getting FESCo’s input on the priorities and soft requirements will be incredibly valuable for identifying blockers before development begins.

Any thoughts on the best way to sync up? Most of the team is usually on the matrix channel (although the last week or so has been light on due to Flock and PTO). We also have daily sync-ups and out scrum meetings on google meet.

For reference, here is the full team working on this phase:

Thanks for opening the ticket and bringing this up. It’s great to get FESCo involved on the distgit/src.fp.o migration. As we wrap up the Pagure.io shutdown, the timing is perfect to start aligning on the next phase. @humaton is currently working on the requirements, and getting FESCo’s input on the priorities and soft requirements will be incredibly valuable for identifying blockers before development begins. Any thoughts on the best way to sync up? Most of the team is usually on the matrix channel (although the last week or so has been light on due to Flock and PTO). We also have daily sync-ups and out scrum meetings on google meet. For reference, here is the full team working on this phase: * Product Owner: @humaton * Scrum Master: @rcallwoo * Development Team: * @amedvede * @dkirwan * @lenkaseg * @nphilipp * @t0xic0der * @ryanlerch
Author
Owner

👋 Thanks for the thorough response!

@humaton is currently working on the requirements, and getting FESCo’s input on the priorities and soft requirements will be incredibly valuable for identifying blockers before development begins.

That sounds perfect. We can definitely provide feedback on the requirements/priorities once @humaton is done working on them.

Any thoughts on the best way to sync up? Most of the team is usually on the matrix channel (although the last week or so has been light on due to Flock and PTO). We also have daily sync-ups and out scrum meetings on google meet.

Got it. When do these meetings happen? Would it be possible for a representative or representatives of the team to come to a FESCo meeting for opening discussion? FESCo meetings are currently every Tuesday at 18:00 Europe/London (currently 17:00 UTC) on Matrix chat, and we can add this topic to the agenda which is sent out ahead of time. After that, it'd be good to have a channel for regular communication/checking in, whether that's something asynchronous1, a FESCo->Forge liaison, and/or a recurring FESCo meeting agenda item.


  1. which is easier with FESCo and the Forge team as a whole being spread across ~7 timezones :) ↩︎

:wave: Thanks for the thorough response! > @humaton is currently working on the requirements, and getting FESCo’s input on the priorities and soft requirements will be incredibly valuable for identifying blockers before development begins. That sounds perfect. We can definitely provide feedback on the requirements/priorities once @humaton is done working on them. > Any thoughts on the best way to sync up? Most of the team is usually on the matrix channel (although the last week or so has been light on due to Flock and PTO). We also have daily sync-ups and out scrum meetings on google meet. Got it. When do these meetings happen? Would it be possible for a representative or representatives of the team to come to a FESCo meeting for opening discussion? FESCo meetings are currently every Tuesday at 18:00 Europe/London (currently 17:00 UTC) on Matrix chat, and we can add this topic to the agenda which is sent out ahead of time. After that, it'd be good to have a channel for regular communication/checking in, whether that's something asynchronous[^1], a FESCo->Forge liaison, and/or a recurring FESCo meeting agenda item. [^1]: which is easier with FESCo and the Forge team as a whole being spread across ~7 timezones :)
Author
Owner

These are the "special" things that I know of which are implemented in our current setup and are important for enforcing policy and/or standard packager or releng workflows.

  • Handling features currently implemented by pagure-dist-git. Is the plan to create a separate service for these?
  • Orphaning and re-claiming packages as part of the Orphaned Packages Process
  • Setting Anitya monitoring settings
  • Setting Bugzilla assignees
  • Syncing dist-git repo "watchers" with Bugzilla
  • Enforcing push rules
    • Preventing force pushes (but allowing them on forks)
    • Preventing branch deletion (but allowing it on forks)
    • Preventing pushing to retired or EOL branches
    • Allowing provenpackagers to override PR requirements to enable rebuilds or mass package changes
  • Handling permissions
    • Syncing existing per-package ACLs for users and groups
    • Handling groups/SIGs across namespaces/orgs (rpms, flatpaks, tests, etc.). Will each group be duplicated as a separate team in each Forgejo org?
    • Out-of-band syncing of group memberships from the accounts system to dist-git. When someone is removed from packager, provenpackager, or another SIG that is synced to dist-git, they should immediately be removed from the corresponding group/team in dist-git so they can't still push to repositories via token or SSH key. For Pagure dist git, syncing group deletions is currently handled by a Toddler.
    • Expose package ACL information (main admin, committers, group, etc.). Pagure shows this by default, but Forgejo doesn't.
    • What about collaborator access for epel branch access? Is there an analogue to this in Forgejo? (I am personally not a fan of having maintainers only for specific branches, anyways, but current policies do endorse this.)
  • Updating fedpkg and other tools and releng scripts
  • Make it possible to push via SSH. I know there are various schools of thought here, but I believe most packagers expect this to work.
    • Bonus: Use SSH keys stored in FAS instead of requiring them to be set up again in Forgejo.

Integrations

These integrations with other services are also important to the packager workflow. I believe the CI features are maintained by the Packit team, and we should coordinate with that team to make sure those integrations are adapted to work with the Forgejo-based dist-git before the migration.

  • Fedora Messaging integration for pushes and PR events
  • Distgit CI (scratch builds, installability checks, etc.)
  • Packit upstream <-> downstream sync jobs
  • Bodhi. It currently uses the Pagure API to get package maintainers (and also for other uses?)
These are the "special" things that I know of which are implemented in our current setup and are important for enforcing policy and/or standard packager or releng workflows. - Handling features currently implemented by pagure-dist-git. Is the plan to create a separate service for these? - Orphaning and re-claiming packages as part of the Orphaned Packages Process - Setting Anitya monitoring settings - Setting Bugzilla assignees - Syncing dist-git repo "watchers" with Bugzilla - **Enforcing push rules** - Preventing force pushes (but allowing them on forks) - Preventing branch deletion (but allowing it on forks) - Preventing pushing to retired or EOL branches - Allowing provenpackagers to override PR requirements to enable rebuilds or mass package changes - **Handling permissions** - Syncing existing per-package ACLs for users and groups - Handling groups/SIGs across namespaces/orgs (`rpms`, `flatpaks`, `tests`, etc.). Will each group be duplicated as a separate team in each Forgejo org? - Out-of-band syncing of group memberships from the accounts system to dist-git. When someone is removed from `packager`, `provenpackager`, or another SIG that is synced to dist-git, they should immediately be removed from the corresponding group/team in dist-git so they can't still push to repositories via token or SSH key. For Pagure dist git, syncing group deletions is currently handled by a Toddler. - Expose package ACL information (main admin, committers, group, etc.). Pagure shows this by default, but Forgejo doesn't. - UI - Project API (currently used by the orphaned packages process script and potentially others) - Something resembling the consolidated data that's available at <https://src.fedoraproject.org/extras/> but ideally without the flaws mentioned in https://pagure.io/pagure-dist-git/issue/155 (currently used by the FESCo SIG Policy script and potentially others) - What about `collaborator` access for epel branch access? Is there an analogue to this in Forgejo? (I am personally not a fan of having maintainers only for specific branches, anyways, but current policies do endorse this.) - Updating fedpkg and other tools and releng scripts - Make it possible to push via SSH. I know there are various schools of thought here, but I believe most packagers expect this to work. - Bonus: Use SSH keys stored in FAS instead of requiring them to be set up again in Forgejo. ## Integrations These integrations with other services are also important to the packager workflow. I believe the CI features are maintained by the Packit team, and we should coordinate with that team to make sure those integrations are adapted to work with the Forgejo-based dist-git before the migration. - Fedora Messaging integration for pushes and PR events - Distgit CI (scratch builds, installability checks, etc.) - Packit upstream <-> downstream sync jobs - Bodhi. It currently uses the Pagure API to get package maintainers (and also for other uses?)
Owner

+1 to all above, plus one thing I have been thinking about: The permission system in forgejo allows "admin" type users to do a lot of settings changes to repositories that are definitely not desirable for a dist-git setup:

  • disabling branch protections (enabling force-pushes / branch deletions)
  • turning on / off "Units" (PRs, issues, Wiki, etc.)
  • and more

Might it make sense to not give full "admin" permissions on dist-git repos to regular packagers at all? I.e. only give them "member" type access to their own packages, and (if possible?) permissions to add / remove other "member"s access to the package repo.

+1 to all above, plus one thing I have been thinking about: The permission system in forgejo allows "admin" type users to do *a lot* of settings changes to repositories that are definitely not desirable for a dist-git setup: - disabling branch protections (enabling force-pushes / branch deletions) - turning on / off "Units" (PRs, issues, Wiki, etc.) - and more Might it make sense to not give full "admin" permissions on dist-git repos to regular packagers *at all*? I.e. only give them "member" type access to their own packages, and (if possible?) permissions to add / remove other "member"s access to the package repo.
Owner

Most likely the forgejo codebase for dist-git will have to be another fork, since it's not flexible enough to support our needs as-is.

Most likely the forgejo codebase for dist-git will have to be another fork, since it's not flexible enough to support our needs as-is.

I also forgot to mention too -- there is a staging instance set up already:

https://http-dist-git.apps.ocp.stg.fedoraproject.org/explore/repos

note that this has no dist-git specific patches as yet, but when it was made the 40K or so packages (repos) were imported from pagure dist git.

I also forgot to mention too -- there is a staging instance set up already: https://http-dist-git.apps.ocp.stg.fedoraproject.org/explore/repos note that this has no dist-git specific patches as yet, but when it was made the 40K or so packages (repos) were imported from pagure dist git.
Owner

Do we know what the source of the syntax highlighting code is? It looks like it needs updating for new syntax constructions.

Do we know what the source of the syntax highlighting code is? It looks like it needs updating for new syntax constructions.

If there's going to be any discussion/meeting related to forge migration, can you please invite me and @lecris ? A lot is related to Packit and Fedora dist-git CI so would be good to be kept in the loop... Thanks!

If there's going to be any discussion/meeting related to forge migration, can you please invite me and @lecris ? A lot is related to Packit and Fedora dist-git CI so would be good to be kept in the loop... Thanks!
Author
Owner

@lachmanfrantisek, thanks for your comment. I had it on my list to reach out to the Packit team so happy you are in the loop now! I just updated #3623 (comment) to add an Integrations section. Does that look correct to you? You and @lecris are also of course invited to the meeting. I can ping you once it's on the agenda.

@lachmanfrantisek, thanks for your comment. I had it on my list to reach out to the Packit team so happy you are in the loop now! I just updated https://forge.fedoraproject.org/fesco/tickets/issues/3623#issuecomment-878538 to add an Integrations section. Does that look correct to you? You and @lecris are also of course invited to the meeting. I can ping you once it's on the agenda.
Author
Owner

CC @humaton @lachmanfrantisek @lecris

This ticket is tagged with meeting, so it is planned to be discussed at the next meeting on Tuesday, July 14th at 18:00 Europe/London (currently 17:00 UTC) in https://matrix.to/#/#meeting:fedoraproject.org.

CC @humaton @lachmanfrantisek @lecris This ticket is tagged with `meeting`, so it is planned to be discussed at the next meeting on Tuesday, July 14th at 18:00 Europe/London (currently 17:00 UTC) in <https://matrix.to/#/#meeting:fedoraproject.org>.

Not sure if the meeting would be to schedule some meeting or discuss the actual topics.

so it is planned to be discussed at the next meeting on Tuesday, July 14th at 18:00 Europe/London (currently 17:00 UTC)

I will be at a conference, but I will try to at least be semi-present

@gotmax23 wrote in #3623 (comment):

I just updated #3623 (comment) to add an Integrations section.

Yes, looks ok, nailed the specifics of what is affected and needs patching. Another thing that was brought to my attention is the need to patch bodhi as well.

@ryanlerch wrote in #3623 (comment):

I also forgot to mention too -- there is a staging instance set up already:

https://http-dist-git.apps.ocp.stg.fedoraproject.org/explore/repos

Thanks, would probably need access to some repos to mock a PR activity. Also interested to see how the "admin" packager access would look in there.

Not sure if the meeting would be to schedule some meeting or discuss the actual topics. > so it is planned to be discussed at the next meeting on Tuesday, July 14th at 18:00 Europe/London (currently 17:00 UTC) I will be at a conference, but I will try to at least be semi-present @gotmax23 wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3623#issuecomment-1058934: > I just updated #3623 (comment) to add an Integrations section. Yes, looks ok, nailed the specifics of what is affected and needs patching. Another thing that was brought to my attention is the need to patch bodhi as well. @ryanlerch wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3623#issuecomment-1057949: > I also forgot to mention too -- there is a staging instance set up already: > > https://http-dist-git.apps.ocp.stg.fedoraproject.org/explore/repos Thanks, would probably need access to some repos to mock a PR activity. Also interested to see how the "admin" packager access would look in there.

Since @lachmanfrantisek is on PTO this week, I will attend in his stead.


also going forward I’ll probably drive it on the Packit’s side, so Frantisek doesn’t have so much on his plate

Since @lachmanfrantisek is on PTO this week, I will attend in his stead. --- also going forward I’ll probably drive it on the Packit’s side, so Frantisek doesn’t have so much on his plate
Author
Owner

lecris wrote in #3623 (comment):

Another thing that was brought to my attention is the need to patch bodhi as well.

I have added Bodhi to the list of Integrations. Thanks for pointing that out.

lecris wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3623#issuecomment-1062205: > Another thing that was brought to my attention is the need to patch bodhi as well. I have added Bodhi to the list of Integrations. Thanks for pointing that out.

There is also this investigation done by the ARC team https://fedora-arc.readthedocs.io/en/latest/dist-git-move/index.html#

There is also this investigation done by the ARC team https://fedora-arc.readthedocs.io/en/latest/dist-git-move/index.html#
Author
Owner

This was discussed in last meeting (meeting log). Thanks to humaton, mfocko, and lecris for joining!

ACTION: jednorozec to publish the roadmap to dist-git migration in tracker(s) and on Fedora Manazine. FESco to evaluate and discuss after.

There was also some discussion about how to best handle ongoing communication between FESCo, the community, and the Forge team about the distgit migration effort. We did not reach any definitive conclusion there.

This was discussed in last meeting ([meeting log](https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-07-14/fesco.2026-07-14-17.00.log.html)). Thanks to humaton, mfocko, and lecris for joining! > ACTION: jednorozec to publish the roadmap to dist-git migration in tracker(s) and on Fedora Manazine. FESco to evaluate and discuss after. There was also some discussion about how to best handle ongoing communication between FESCo, the community, and the Forge team about the distgit migration effort. We did not reach any definitive conclusion there.
Sign in to join this conversation.
No milestone
No project
No assignees
9 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
fesco/tickets#3623
No description provided.