fedora-infrastructure

#12737 Restructuring Infrastructure and Release Engineering Repositories in Forgejo
Closed: Migrated to Fedora Forge by ryanlerch. Opened by humaton.

Closed: Migrated to Fedora Forge
Reopen Issue

To create a more unified and organized environment within our new Forgejo instance, this proposal outlines a new structure for the Infrastructure and Release Engineering repositories. The goal is to improve clarity, streamline ticket tracking, and provide a centralized home for all application code, making it easier for new contributors to get involved.

Proposed Organizational Structure

I propose the creation of two distinct organizations:

Infrastructure: This organization will house repositories specific to infrastructure management. It will include a dedicated ticketing repository to replace the current tracker at https://pagure.io/fedora-infrastructure.

Release Engineering: This organization will contain repositories related to the release engineering process, such as failed-composes. It will also feature a dedicated ticketing repository to replace the one at https://pagure.io/releng.

These two organizations will be dedicated solely to their respective operational and engineering functions and will not be used for hosting application code.

Application Code Repository Consolidation

To centralize our development efforts, I propose creating a third organization:

Websites & Apps: All application code repositories currently located on pagure.io and GitLab will be migrated to this organization. This includes all applications actively developed and maintained by the CLE team.

By creating a unified home for all our applications, we can significantly lower the barrier to entry for new contributors. Each application repository will maintain its issue tracker, preserving the current workflow for development and maintenance.

Benefits

This restructuring will offer several key advantages:

Improved Organization: Separating infrastructure, release engineering, and application code into distinct organizations will create a more logical and manageable repository structure.

Enhanced Clarity: A clear and intuitive layout will make it easier for everyone, especially newcomers, to navigate our projects and understand where to find specific resources.

Centralized Development: Consolidating all application code will streamline development efforts and simplify the onboarding process for new team members.

Metadata Update from @james:
- Issue priority set to: Waiting on External (was: Needs Review)
- Issue tagged with: high-trouble, medium-gain

A few questions:

Is ansible 'an application' ? Would it be under infra as a sub org? or ?

When you say 'such as failed-composes' you mean... the tracker that that uses? where the code for the app that files the issues is under websites & apps? or ?

What about github.com/fedora-infra ? many/lots of our applications are there.

Websites & apps seems like it combines two kind of different areas, should we perhaps have seperate 'websites' and 'applications' orgs?

There's also a number of projects that IMHO we can just save off an archive of (for historical reasons) and not migrate.

Oh and a side note: I think no org should normally have 'fedora' in the name. Since they are on a fedoraproject.org domain.

A few questions:

Is ansible 'an application' ? Would it be under infra as a sub org? or ?

This is where it might get a bit difficult, here is a loose list i made (doenst cover everything), but not sure lumping scripts and stuff in "Applications" is the right fit.

Infrastructure
- infra-docs-fpo
- fedora-infrastructure
- ansible
- arc
- fedora-infrastructure-old-repo (archived)
- howtos (archived)

ReleaseEngineering
- releng
- failed-composes

Applications
- fedora-koji-web
- koji
- firmitas-staging-tracker
- ipsilon-fedora
- mailman-stack-maint
- packager-sync-bz
- review_stats
- toddlers
- w2fm-migration
- cookiecutter-python-app
- distgit-bugzilla-sync (archived)
- generate_changelog (archived)
- loopabull-tasks (archived)
- mirror_from_pagure (archived)
- python-munch (archived)
- rpmautospec (archived)
- zuul (archived)

Websites
- fedoraproject.org CMS
- fedora-websites-3.0

What about github.com/fedora-infra ? many/lots of our applications are there.
Oh, I think we can migrate the ones that the teams want to, if they want to move.

There's also a number of projects that IMHO we can just save off an archive of (for historical reasons) and not migrate.

I'd like to see us migrate the old pagure.io ones over, and then archive them straight away, so we have the history, but close them off (you can archive in forgejo, unlike pagure)

Oh and a side note: I think no org should normally have 'fedora' in the name. Since they are on a fedoraproject.org domain.

+100 agree to this

This is where it might get a bit difficult, here is a loose list i made (doenst cover everything), but not sure lumping scripts and stuff in "Applications" is the right fit.

Infrastructure
- infra-docs-fpo
- fedora-infrastructure

We may be able to retire this one. Perhaps we could retire it and put the ansible repo in it's place?
(That would perhaps allow for things like closing issues when a pr that addresses them is pushed, etc)

we still use howtos: https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/#_howtos

ReleaseEngineering
- releng
- failed-composes

Applications
- fedora-koji-web
- koji

This is fuzzy to me. Yes, this is an application, yes we deploy and use it... but it's also used by a lot of other places. It's 'upstream' of us. We also don't really work on it, it's some other folks at Red Hat.
I guess we could ask them what they want to do... but being in our applications space implies that we are the ones who work on it right?

This might go under infra? it's to track packaging mailman for our use. Or perhaps it can be archived now?

Can we rename it poddlers as part of the move? :)

We use this. It's the thing that runs on batcave01 and listens for messages and syncs our local copy of the ansible repo.
This will of course have to be adjusted for forgejo.

This depends on the CI situation in forge.fp.o. Are we just adjusting zuul or using something else. If zuul this will need to stay around.

Websites
- fedoraproject.org CMS
- fedora-websites-3.0

There's likely a ton of other websites stuff... fedora-web/* etc.
Should infra-docs-fpo be under websites? Or under infrastructure?

Oh, and all these need to be under releng IMHO:

https://pagure.io/fedora-comps
https://pagure.io/fedora-kickstarts/
https://pagure.io/fedora-kiwi-descriptions/
https://pagure.io/workstation-ostree-config
https://pagure.io/pungi-fedora

and probibly more. Would likely be good to look at branching docs and list everything thats touched there.

and...

https://pagure.io/pungi is in the same boat as koji. It's something we use a lot, but we don't maintain it...

Can we rename it poddlers as part of the move? :)

Actually, I would prefer renaming our deployment in ansible to "toddlers". The "poddlers" name was a (very funny, yes yes) pun on the fact that the deployment will use multiple pods, but the app name is still toddlers and now that we don't need a separate name to run both in parallel, the toddlers deployment should be renamed back to toddlers I think.

ok, fair point on that.

Oh and a side note: I think no org should normally have 'fedora' in the name. Since they are on a fedoraproject.org domain.

I definitely agree with this.

In the same vein, I suggest we standardize on using simple lowercase organization names to have shorter/nicer/cleaner URLs. We can still set a longer name as the organization full name. We do this with our org on Codeberg.

  • org name: fedora
  • org full name: Fedora Project

That would work out as follows with the orgs that have been brought up so far.

  • Infrastructure :arrow_right: infra
  • ReleaseEngineering :arrow_right: releng
  • Applications :arrow_right: apps
  • Websites :arrow_right: websites

I also noticed we already have a Community-Linux-Engineering org, which could be be renamed to cle.

Okay, so from what I am seeing on this thread, that a group layout like the following will suit most of the repos we are talking about.

  • infra Infrastructure
  • releng Release Engineering
  • apps Applications
  • websites Websites
  • cle Community Linux Engineering
  • epel EPEL

the fullname for EPEL i left alone, as i feel it has transcended from an acronym to full word status, a-la- SCUBA, RADAR, and LASER

This is fuzzy to me. Yes, this is an application, yes we deploy and use it... but it's also used by a lot of other places. It's 'upstream' of us. We also don't really work on it, it's some other folks at Red Hat.
I guess we could ask them what they want to do... but being in our applications space implies that we are the ones who work on it right?

Yeah, been thinking about this a bit, and we don't have many cases for this, but if they do want to move this to Fedora Forge (rather than codeberg or something else), do you think this is enough of an edge case for a specific "Koji" organization? Its not tied directly to a SIG or a group, but it is quite tied to Fedora, so it has a solid case to be included.

So, all those would be top level? or are we doing a flat tree anyhow?

I could make a case for epel being under sigs or under editions/subprojects if we are doing a tree...

as for pungi and koji... not sure.

@mikem and @lsedlar care to weigh in? would you prefer to move from pagure.io to forge.fedoraproject.org as a 'fedora' project or just move to codeberg/whatever as you choose to be more an independent upstream?

the fullname for EPEL i left alone, as i feel it has transcended from an acronym to full word status, a-la- SCUBA, RADAR, and LASER

While I appreciate the sentiment, I don't mind spelling it out as Extra Packages for Enterprise Linux in the full name, as long as the regular name is just epel for URLs.

I could make a case for epel being under sigs or under editions/subprojects if we are doing a tree...

Yay, time to revisit the identity crisis of "Is EPEL a SIG, an edition, an initiative, a subproject, or something else?" :grinning:

Currently we're working in two repo:

I could see this as the future layout:

Or if people don't like epel being both a repo and an org in different contexts, we could do something like:

I can bring this up at the next ESC meeting to see if folks have strong feelings about separating issues and docs or about having an epel org.
  • apps Applications
  • websites Websites

I wonder if sites would be better than websites? Are all future sites going to be web/HTTP(S) sites? We actually have an open ticket already requesting that a gemini:// site be created.

  • https://en.wikipedia.org/wiki/Gemini_(protocol)
  • https://gitlab.com/fedora/websites-apps/fedora-websites/fedora-websites-3.0/-/issues/271

So, all those would be top level? or are we doing a flat tree anyhow?

forgejo is flat-tree only -- same concept as github orgs (gitlab has nested groups/orgs though)

@mikem and @lsedlar care to weigh in? would you prefer to move from pagure.io to forge.fedoraproject.org as a 'fedora' project or just move to codeberg/whatever as you choose to be more an independent upstream?

IMO both options are fair for Pungi. Fedora is a big user, but there is at least another use case in Red Hat. Wherever it moves, the pagure.io repos for compose-utils and releng/python-multilib should like go with it. It might boil down to functionality. Is forge.fedoraproject.org going to support some kind of CI and are we okay running pull requests tests on it?

Another interesting use case is fedpkg and fedpkg-minimal. Those would make most sense for me to be fully Fedora projects (CC @onosek). And rpkg should probably remain next to fedpkg?

Hmm, I had previously assumed that the pagure to forgejo migration would continue to support independent projects. I see now that this is not the case.

While Fedora is a hugely important consumer for Koji, there are many others. Infra doesn't own the Koji upstream, nor does any other group or sig in Fedora.

I have a number of other Koji-adjacent repos (and mbs too) in pagure that are in a similar boat. If there is no longer going to be an offering for more independent repos here, then I guess I'll need to look elsewhere. I wish I'd realized this was the case earlier. I've been holding off on leaving pagure because I assumed I'd be moving to this.

Yeah, we decided there wasn't any reason for us to run a general source forge with forgejo when codeberg is right there and thats it's purpose...

@mikem and @lsedlar care to weigh in? would you prefer to move from pagure.io to forge.fedoraproject.org as a 'fedora' project or just move to codeberg/whatever as you choose to be more an independent upstream?

IMO both options are fair for Pungi. Fedora is a big user, but there is at least another use case in Red Hat. Wherever it moves, the pagure.io repos for compose-utils and releng/python-multilib should like go with it. It might boil down to functionality. Is forge.fedoraproject.org going to support some kind of CI and are we okay running pull requests tests on it?

I think this will be required for other projects, so I think thats going to be supported.

Another interesting use case is fedpkg and fedpkg-minimal. Those would make most sense for me to be fully Fedora projects (CC @onosek). And rpkg should probably remain next to fedpkg?

yes.

Hmm, I had previously assumed that the pagure to forgejo migration would continue to support independent projects. I see now that this is not the case.

While Fedora is a hugely important consumer for Koji, there are many others. Infra doesn't own the Koji upstream, nor does any other group or sig in Fedora.

Yep.

I have a number of other Koji-adjacent repos (and mbs too) in pagure that are in a similar boat. If there is no longer going to be an offering for more independent repos here, then I guess I'll need to look elsewhere. I wish I'd realized this was the case earlier. I've been holding off on leaving pagure because I assumed I'd be moving to this.

pagure.io isn't going anywhere short term, there's lots of time. At least IMHO.

So, where are we here? I guess we need to create an exact mapping of what is on pagure.io that we want to move and where we want to move it to?

we did open a more specific ticket for infra and I think there's one for releng too. Is there any meta topics we wanted to still figure out here?

@mikem TBH, it is my optinion that koji and related projects are close enough to Fedora to warrant an organization(s) on fedora forge (if you want to move there).

Koji is a well-established project with close ties to Fedora, so belongs in the new forge. (my opinion)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/infra/tickets/issues/12737

Please continue any further discussion there.

Metadata Update from @ryanlerch:
- Issue close_status updated to: Migrated to Fedora Forge
- Issue status updated to: Closed (was: Open)
Metadata
None

high-trouble medium-gain

None
None
Highest
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.