After extensive review and discussion on the ticket request and in recent council meetings (see meetbot for 29 July and 15 July 2026), the Fedora Council would like to initiate the policy change policy process for ratifying the Fedora Forge Usage policy. This document is open to public feedback (if any) for a minimum of two weeks. If there are no significant changes to be made to the policy based on community feedback after Thursday, 13 August 2026, this policy will go to a formal ticket vote for Council to approve or reject.
If there are significant changes to be made to the document, Council will review the policy and, if necessary, extend the feedback period before calling for an official vote. Please provide feedback on the discussion post.

The policy can be found on the Council wiki page in Fedora Forge, posted on discourse, and pasted below here for convenience.

Thank you everyone for your contributions to this policy so far, and on behalf of the Council, we look forward to working with you all to ratify this policy soon.

Fedora Forge Usage Policy

Welcome to the Fedora Forge. This Forgejo instance is provided by the Fedora Infrastructure team to support the daily operations, development, and collaboration of the Fedora Project.

To ensure this service remains reliable, secure, and useful for everyone in the Fedora community, all users must adhere to the following usage policy.

1. Scope, Criteria, and Exceptions

The Fedora Forge is a dedicated workspace for the Fedora Project. Historically, the Fedora Project utilized pagure.io, which operated as a general-use public forge where Fedora repositories coexisted alongside personal projects, unrelated upstream software, and individual portfolios.

The Fedora Forge (powered by Forgejo) intentionally adopts a narrower scope. It is not a public, general-use Git hosting provider. It is an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.

Criteria for “Fedora Project Related”

To qualify for hosting on the Fedora Forge, a repository must meet at least one of the following criteria:

• Infrastructure and Operations: Configuration management, deployment scripts, or tooling used by the Fedora Infrastructure team to run the project.
• Release Engineering and Packaging: Tools, scripts, and templates used to build, compose, and distribute Fedora releases, editions, and spins.
• Governance and Team Organization: Trackers, documentation, and collaborative spaces for official Fedora Teams, Special Interest Groups (SIGs), Working Groups, and Fedora Council initiatives.
• Fedora-Specific Software: Software projects conceptualized and developed primarily to serve the Fedora community (e.g., Fedora Badges, Bodhi, fedmsg).

Exceptions and Special Cases (Ecosystem Upstreams)

While general upstream development should happen on public forges (like GitHub, GitLab, or Codeberg), the Fedora Project recognizes that certain large-scale upstream projects are so deeply intertwined with Fedora’s infrastructure and history that they qualify as exceptions.

Recognized Exceptions:

• Foundational infrastructure tools heavily maintained by Fedora and Red Hat ecosystem contributors (e.g., Koji, FreeIPA).
• Core system components where the primary development team is historically rooted in the Fedora community and relies on Fedora Infrastructure for their workflow.

Note: Being packaged in the Fedora repository does not automatically grant a project exception status to use the Fedora Forge as its upstream host.

Decision Process for Edge Cases

If a community member is unsure whether their project fits the scope or qualifies as an ecosystem exception, the following process applies:

1. Request Submission: The requester must open a ticket on the Fedora Infrastructure tracker, detailing the project’s purpose, its connection to Fedora, and why it should be hosted on the Fedora Forge rather than a public alternative.
2. Infrastructure Review: The Fedora Infrastructure team will conduct an initial review against the established criteria to assess technical feasibility and resource impact.
3. Steering Committee Consultation: If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) or the Fedora Council for a policy ruling.
4. Final Resolution: The decision will be documented in the ticket. If denied, the requester will be encouraged to host the project on a public forge and mirror specific components if strictly required for internal Fedora builds.

2. Access and Authentication

Access to the Fedora Forge is integrated with our central identity systems to ensure secure and accountable access.

• Account Creation and Login: All authentication is handled via the Fedora Account System (FAS). You cannot create a local account directly on the Forgejo instance. To log in, use the Single Sign-On (SSO) integration with your active FAS credentials.
• Personal Namespaces: Upon your first login, a personal namespace (e.g., forge.fedoraproject.org/your-fas-username) is automatically provisioned for you. You can only fork repositories into this space, creation of new repositories is allowed only under Organization.
• Organizations and Teams: To prevent organizational sprawl, the creation of top-level Organizations (e.g., /infra or /quality) is restricted. If your Fedora team or SIG needs a dedicated Organization space, please open a ticket with the Forge team. Organization owners are responsible for managing team access within their assigned space.
• Account Deactivation: If your FAS account is suspended, disabled, or marked as inactive, your access to the Fedora Forge will be automatically revoked. Repositories hosted in your personal namespace may be archived or removed if your account remains inactive for an extended period. If you are leaving the project, please transfer ownership of any critical tools to a Fedora Organization or an active co-maintainer before your departure.

3. Code of Conduct and Community Behavior

The Fedora Forge is a collaborative space. All activity on this platform is strictly governed by the Fedora Code of Conduct.

4. Prohibited Activities

To ensure the Fedora Forge remains performant, secure, and legally compliant, the following activities and content are strictly prohibited:

• Non-Fedora Projects: As stated in the scope, this Forge is not a general-purpose Git host. Personal portfolios, dotfiles, or hobby projects not directly tied to Fedora are prohibited.
• Malicious Content: Hosting malware, exploits, botnet command-and-control infrastructure, or phishing materials. (Note: Security-related tools strictly used for Fedora infrastructure testing must be explicitly approved).
• Proprietary and Copyrighted Material: Uploading copyrighted materials you do not have the right to distribute, or hosting proprietary, closed-source binary blobs. All code should be open source and compliant with Fedora’s licensing guidelines.
• Exposing Secrets: Committing sensitive information such as passwords, API tokens, private SSH keys, or Personally Identifiable Information (PII).
• System Abuse: Engaging in activities that degrade the performance of the Forgejo instance or its runners, such as aggressive network scraping, DDoS attacks, or intentionally triggering infinite CI loops.
• Cryptocurrency Mining: Using the Forge or its CI/CD runners to mine cryptocurrency is strictly forbidden and will result in an immediate, permanent ban.

5. Resource Limits and CI/CD

We want to empower Fedora teams with the tools they need, but we must also manage our infrastructure costs and storage effectively.

• Repository Size: Git is not a backup system. Please keep repositories focused on source code and text-based documentation.
  • Repositories should ideally remain under 500MB.
  • If your project requires large assets (e.g., design files, test datasets), you must use Git LFS (Large File Storage).
• Forgejo Actions and CI Runners:
  • Shared Infrastructure: The default CI runners provided by Fedora Infrastructure are a shared community resource. Jobs should be optimized to run efficiently and are subject to a maximum timeout of 10 minutes per job.
  • Community-Owned Runners (Bring Your Own): We highly encourage larger teams, SIGs, and Working Groups with extensive testing or specific architectural requirements (e.g., heavily utilizing ARM, RISCV, or requiring long build times) to provision and register their own runners. Dedicated runners can be attached directly to your Organization or specific repositories.
  • Compliance for Custom Runners: Even if your team provides the compute resources, any runner connected to the Fedora Forge is an extension of our infrastructure. All workflows and actions executed on community-owned runners must strictly comply with Section 4 (Prohibited Activities). You may not use custom runners to bypass policy (e.g., no cryptocurrency mining, no building unrelated non-Fedora upstream projects, and no malicious network scraping).
  • Registration Process: To register a dedicated runner for your team, please review our Runner Registration Docs and ensure your runner is secured according to Fedora Infrastructure standards.
• API Usage: Automated scripts and bots interacting with the Forgejo API must respect rate limits and include descriptive user-agent strings identifying the tool and its maintainer.

6. Repository Lifecycle and Organization

• Naming Conventions: We have a general naming convention, there should be tickets repository in your Organisation to have a single point of opening tickets relevant to your group. The docs repo in you organization should point to your groups official sources for docs.fedoraproject.org namespace. In other cases please use clear, descriptive names for repositories so other community members can easily understand their purpose.
• Archiving: Projects that are no longer actively maintained should be archived (marked as read-only) to signal their status to the community. Active Forge organization owners should archive repos as necessary. If needed (e.g., in the case of an inactive organization), the Infrastructure team reserves the right to archive repositories that have seen no activity after trying to contact the organization owners.**.
• Deletion: If you need an Organization or repository completely deleted, please open a ticket with the Forge team. The Infrastructure team also reserves the right to delete abandoned, non-compliant, or empty repositories to maintain a clean workspace.

7. Support and Abuse Reporting

• Getting Help: For technical issues with the Fedora Forge (e.g., CI runner failures, login issues, requesting an Organization), please open a ticket on the Forge team tracker or ask in the #fedora-admin Matrix channel.
• Reporting Code of Conduct Violations: To report a CoC violation occurring on the Forge, please contact the Fedora Code of Conduct Committee.
• Reporting Security/Legal Issues: To report a security vulnerability on the platform, exposed secrets, or a DMCA/copyright violation, please immediately send an email to Fedora Infrastructure team.

The post Fedora Forge Usage Policy appeared first on Fedora Community Blog.

Last few years a small team of people in the CLE Team were working each week to prepare a Community update for you. First one published on October 21st 2021. We were starting with only Infrastructure and Release Engineering teams (+ initiatives we did in CPE Team at the time), but later added more teams to our weekly reports to bring people a better picture what is being worked on. We thank to everyone who read our updates and found some value in them.

But as life is going forward even this updates are evolving. Last few weeks @abompard worked together with us to improve his weekly report to include the sources we are using for this weekly reports. So I introduce to you This Week in Fedora as a replacement for Community weekly updates. I’m glad that this initiative I started few years ago was able to live for that long and hopefully helped a few people to find information they were looking for.

I would like to thank people who helped me working on Community weekly updates:

• @lenkaseg
• @jnsamyak
• @c4rt0
• @jskladan
• @t0xic0der
• @siddharthvipul1
• @patrikp

The post End of Community update appeared first on Fedora Community Blog.

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 29 June – 3 July 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

• Planned Outage – download-ib01, torrent, people outage – 2026-06-25 20:00 UTC
• Planned Outage – server moves – 2026-06-25 14:00 UTC
• RFE: Add a role for deploying through OpenShift deployment
• rhel10: colo_virt virthosts
• Migrate ELNBuildSync to Fedora Infrastructure OpenShift

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• Deploy staging el10 signing host for Stream to validate worfklow
• Rebuild all needed pkgs for el10 signing service
• all s390 builders for Stream are unreachable (blocking all rpm build tasks)
• abuse on website
• Init new donated/sponsored server for CentOS infra
• Update Firmware in Risc-V P550’s
• mirror.dsp-lad.space add to mirror list
• Automotive SIG – key rotation
• Change AltImage documentation to use gitlab.com repo
• Update boot-server ansible role for el10
• Renew our yearly RH subscription for CDN access
• migrate status.centos.org to el10

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker

• Continued investigation into building a Fedora container base image using Konflux.
• Continued work on remaining Pagure -> Forgejo migrations.
• F45 release cycle is set to begin soon, starting with Mass Rebuild in the middle of July. This will require some prep work next week.

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

• Discussion with Scaleway (a cloud vendor in France) for potential Fedora Koji builders in their Paris datacenter.  To be coordinated via RISE.
• Hardware
  • Coordinated shipping another “K3” hardware to DavidA (one of the Fedora RISC-V maintainers). This will be used as another RISC-V Koji builder.  Sponsored by CLE.
  • Milk-V Titan hardware is now available to buy.  A handful of machines are being shipped to a couple of  RISC-V engineers, including for Fedora use.
• Community work
  • Fedora Omni kernels for Muse Pi Pro hardware discussion with Trevor from Baylibre and Jason (Fedora RISC-V kernel)
  • Marcin (hrw) Juszkiewicz continues to chip away at the Fedora RISC-V tracker
  • Fedora Omni kernel work continues, with support for Muse Pi Pro, K3, and more: Jason Montleon and Jennifer Berringer
• Other:
  • Discussions on ‘fedora-devel’: “How can we improve the Changes Process?” thread
  • A lot of internal discussion about 2FA for packagers
  • Several internal  and upstreams meetings

AI

This is the summary of the work done regarding AI in Fedora.

• Aurelien Bompard improved the This Week in Fedora script to include the CLE status reports

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

• Lots of PTO: psklenar on extended PTO, kparal and adamwill each took some post-travel PTO days. Also post-event travel, bureaucracy (trip and expense reports) and decompression cut into work time for most
• Compose-critical package script now in MVP state – see pull request, it works and does useful stuff but needs more refinement
• Dist-git PR test feature progress: status report now works, still needs polish and tests
• Tool work: CI optimization in blockerbugs, reverse proxy handling improvement in testdays-web
• Significant bug investigations: grub2 changes broke image builds, haveged update could cause boot failure

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

• Forge 15.0.3 in staging
• New runner for koji organization
• Continued work on Private Issues: public/private comments
• Zabbix template developed to monitor health of runnerhost VM, moving onto the  forge instance next.

EPEL

This team is working on keeping Epel running and helping package things.

• Updated caddy in f44, f43, epel10.3, and epel10.2 resolving 22 CVEs
• EPEL 11 planning discussions

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

• Open Call for Fedora Event Video Footage! [discussions post]
• Feedback period for F45 wallpaper has just ended. Here is the current iteration.

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 27 appeared first on Fedora Community Blog.

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 22 – 26 June 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

• Lost admin permission on packaging/FedoraReview after migrating from Pagure
• Request for IPA admin access on accounts.stg.fedoraproject.org
• Bodhi: only the rawhide package is visible in updates
• Fedora Rawhide mirror 404s

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• Attended/interacted with some Folks contributors (remotely attending and chat in matrix rooms)
• Rebuilt quite some dependencies for calligrabot/robosignatory for centos stream 10 infra change (https://redhat.atlassian.net/browse/CS-3402)
• Continue to work on all needed package rebuild phase for stream signing infra change (https://redhat.atlassian.net/browse/CS-3402)
• Rebuilt already 48 rpm pkgs for infra10s for centos stream signing upgrade (https://redhat.atlassian.net/browse/CS-3402) but unfortunately more to come
• Sprint planning meeting
• Claude helped me writing sms (standup-matrix-summarizer) which can be used to retrieve your “Done” section from each daily standup report, combine that into weekly view so that you can just then copy/paste into manager google doc. See https://gitlab.com/CentOS/infra/containers/standup-matrix-summarizer (and https://quay.io/repository/centos-infra/sms?tab=info)
• Rebuilt more pkgs for centos stream infra but also had to find workaround for orphaned pkg (https://redhat.atlassian.net/browse/CS-3402)
• Rotate some api keys for SIGs (https://gitlab.com/CentOS/infra/tracker/-/work_items/1940)
• Started to work on ansible boot-server role to convert for el10 and isc dhcpd replaced by kea (https://gitlab.com/CentOS/infra/tracker/-/work_items/1936) – WIP
• PoC for kea dhcp replacement for isc dhcpd gone from el10 (https://gitlab.com/CentOS/infra/tracker/-/work_items/1936)
• Created other tickets for .stg. stream el10 staging signing service (network ports for fedora-messaging stg rabbitmq hosts and two new service principals) – https://redhat.atlassian.net/browse/CS-3414
• Closed ticket (review) about all dependencies built and available for el10 robosignatory/calligrabot (https://redhat.atlassian.net/browse/CS-3413)
• Prepared staging host for centos-stream signing (https://redhat.atlassian.net/browse/CS-3414) but now blocked with a fedora infra staging issue (rabbitmq) so tried the whole day to debug but need someone from Fedora infra side to solve the issue there
• Riscv64 discussion about a new p550 hardware firmware upgrade
• Tested and validated that RH network team opened needed port for rabbitmq.stg.fedoraproject.org

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

• F45 rebuild started — we’re trying to first focus on language toolchains — need to refer to Miro’s lightning talk from Flock on how they handled Python bootstrap
• F44 is being kept up2date (there were some big updates, including GCC)
• Kevin did the legwork to move away from old dist-git on fedora.riscv.rocks to forge.fp.o
• Another K3 builder in Fedora Koji — another member added.  (This might sound like a tame update, but all compute power is helpful / important to keep the build momentum :-))
• Discussed some details of riscv64 in primary Koji ticket
• Slides for Flock RISC-V update

AI

This is the summary of the work done regarding AI in Fedora.

• The AI Developer Desktop Remix repos have moved to an org on codeberg (https://codeberg.org/project-resistor)

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

• Flock & DevConf attendance, lruzicka gave a talk on openQA test investigation, adamwill gave a lightning talk with cle about Fedora CI improvements, several of us were involved in a workshop/roundtable about the viability/desirability of moving all testing to dist-git PRs, lots of productive side conversations etc., many about AI – trip reports / blog posts coming
• On-demand openQA test of dist-git PRs in progress
• Looks like we maybe found some new maintainers for packager-dashboard
• Lots of work to enable testing of the huge OpenSSL 4 update for Rawhide, investigate a significant bug that showed up, and eventually bypass the test failures for that bug as it’s proving not to be possible to resolve in a reasonable time (the update needed to get merged)
• Continued tech debt / enhancement work on blockerbugs, testdays-web and issuebot

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

• PTOs & travel
• On Zabbix staging, now have a working template to monitor the Forgejo runnerhost VM and the runners themselves
• Continued work on Private Issues (private comments refactoring)

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

• Beta Wallpaper ticket closed

List of new releases of apps maintained by I&R Team

• Patch update of Fedora Messaging from 3.9.0 to 3.9.1 on 2026-06-23: https://github.com/fedora-infra/fedora-messaging/releases/tag/v3.9.1

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 26 2026 appeared first on Fedora Community Blog.

Updates to translations of Fedora Documentation are again available. As announced on March 3rd, the unavailability of translation updates was due to the migration of the translation repositories and necessary tools from Pagure to the Fedora Forge. It took longer than expected but we are pleased to report this undertaking came finally to the end.

The post Fedora Documentation translations again available appeared first on Fedora Community Blog.

On Saturday May 30th 2026, the XV edition of P.I.W.O. Poznań Free Software Fest was held in Poznań, Poland.

P.I.W.O. is an event with a long history. Between 2004 and 2018, it was organized by various student associations at the Poznań University of Technology. After 2018’s XIII edition (superstition much?), it entered a long hiatus that lasted until 2025, when members of the newly-formed Knyfyrtel Poznań Hackerspace decided to bring it back. The reactivated event proved a huge success, with the XIV edition bringing in 197 attendees. As such, ambitions for 2026 were rather big.

Teamwork makes the dream work

This year’s edition was the result of combined efforts of three Poznań-based organizations:

• Knyfyrtel Hackerspace Poznań
• “Webrains” Students’ Scientific Association at the Adam Mickiewicz University
• “Linux Academic Group” Students’ Scientific Association at the Poznań University of Technology

Thanks to Webrains, for the first time in its history, the event was held at the Adam Mickiewicz University in Poznań – namely, the uni’s Faculty of Mathematics and Computer Science. Also a historical first, the XV edition was granted honorary patronage by the President of Poznań City Council.

Busy, busy day

The event spanned almost the entire Saturday, opening at 9:30 am and closing at 7:35 pm. The agenda was tightly packed, featuring 3 lecture tracks with 24 talks, 2 workshop tracks with 8 activities, plus a LAN Party track with 3 tournaments, as well as “free play” sessions. There was also a quiet corner where, thanks to the “Honte” group, attendees could relax and learn to play Go.

Throughout the years, one of P.I.W.O.’s hallmarks was the lunch break, with the attendees being provided free pizza. This year couldn’t be any different, with some 66m² (or 710 ft²) of pizza being delivered to the venue. (It disappeared frighteningly quick.)

The Fedora Community was represented by:

• Zbyszek Jędrzejewski-Szmek, who gave 2 (!) talks
• Mat Holmes, who volunteered as a photographer
• Kacper Skrzyński, who handled various urgent tasks
• Artur Frenszek-Iwicki, who gave a talk and held a workshop session

Historical moment: creation of SPOIWO

This year’s P.I.W.O. served as an opportunity to announce the creation of SPOIWO – Sojusz Przyjaciół Otwartego i Wolnego Oprogramowania (Alliance of Friends of Open and Free Software). This diverse coalition of social and technology organisations, cooperatives and open source businesses signed a declaration in support of digital sovereignty. The alliance was formed in response to the ever-deepening of public institutions’ dependency on closed platforms and their loss of control over data and communication.

The signing ceremony also featured speeches by representatives of SUSE Poland, Polish Linux User Group, “Internet. Czas działać!” Foundation and PLZ Spółdzielnia.

Exceeding all expectations

The event wrapped with 452 attendee badges issued, which exceeded even the most daring of expectations. (The number also explains why the pizza disappeared so quick.) The bar for the next edition is set high, but so are the organizing team’s ambitions.

If you’d like to learn more about the event, watch the live stream recordings, or subscribe to news so you won’t miss the announcement for the XVI edition – you can do all of that on the event’s website, at piwo.sh.

The post Fedora at XV P.I.W.O. Poznań Free Software Fest appeared first on Fedora Community Blog.

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 15 – 19 June 2026 (Flock Week!!)

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

• Helped getting elnbuildsync moved into stg openshift (ongoing).
• A couple more services had OS upgrades to Fedora 44.
• Some more MirrorManager problems.
• Scrappers found another ostree repo. on kojipkgs, limited dir. indexing to stop the attack and then searched for any other ostree repos. Hopefully the last time it happens.

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• Finish rebuilding/bumping some pkgs for ppc64le libvirt/qemu-kvm stack on el10 (https://gitlab.com/CentOS/infra/tracker/-/work_items/1928)
• Start to work on debuginfo origin servers refresh with el10 instances (https://gitlab.com/CentOS/infra/tracker/-/work_items/1892)
• More coordination work with Stream team about secureboot issues (https://redhat.atlassian.net/browse/CS-3400)
• Finishing last debuginfo pool members reinstall (https://gitlab.com/CentOS/infra/tracker/-/work_items/1892)
• Decommission old openstack env for stream (https://redhat.atlassian.net/browse/CS-3404)
• Cloud SIG doc url change (migration to gitlab, from pagure) – https://gitlab.com/CentOS/infra/tracker/-/work_items/1934
• internal requests (FRCL and audit compliance)
• Move another SIG doc url (away from pagure.io) – https://gitlab.com/CentOS/infra/tracker/-/work_items/1938
• Modified the aws load-balancer settings for one ocp tenant (https://gitlab.com/CentOS/infra/tracker/-/work_items/1932)
• Migrate haproxy load-balancers to el10 for stream dc-move prep (https://redhat.atlassian.net/browse/CS-3353)

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker

• Migration at 95%, the only thing left to migrate is majorly fedora-scm-requests, bug fixes, and continued releng operations.
• Migration: archive-repo-manager from pagure
• Fix: Missing permissions on releng/fedora-comps
• Bug Fix: Mass tagging script for verification bits
• F45 Change Sets reviews are in check and f45-python side tags are merged.
• Regular releng operations.

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

• We’ve started searching for new owners/maintainers of Packager Dashboard and Oraculum

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

• Completed the Flock To Fedora 2026 presentation on Fedora → Forgejo migration efforts #588, packaged and deployed Forgejo 15.0.3 #620.
• successfully ran the PR fix doctor across all migrated repositories #601 to address merge issues with Pagure imports.
• Enhanced runner infrastructure with the addition of a Testing Farm runner option #619 and docker-slim type runner #568, and improved security by deploying oauth-proxy to secure the Forge metrics endpoint #571.

EPEL

This team is working on keeping Epel running and helping package things.

• Updated caddy in rawhide, resolving 14 CVEs
• Ongoing onboarding of Pedro

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

• With Flock this week, got to see how all the final designs turned out it in person!
• Emma delivered her talk on ‘Why You Should Use Open Source Design in Open Source’ at Flock
• Great progress on the F45 wallpaper in the final stretch!

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 25, 2026 appeared first on Fedora Community Blog.

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 08 – 12 June 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

• Request for CentOS Alternative Images SIG URL Update
• Wiki upgrade problems/patch with FedoraMessaging when editing a page
• Staging wiki down due to PluggableAuth extension issue
• Move all remaining Fedora 42 instances to 44
• Deploy DRM Panic Frontend
• Switch from session-based OIDC to Authentication Bearer
• Move the Fedora Badges static assets from Pagure to Forgejo
• badges: fix image trigger annote order on deploy metadata
• List authorization in CORS headers for API routes

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• Fix backup cache DB mismatch on backup machine
• Change isa riscv %dist to .el10rv
• Reinstall failed sponsored server
• rebase needed qemu-kvm/libvirt stack for ppc64le hypervisor role
• Refresh new RHEL releases on deployment server[s]
• Deploy new donated machine (and onboard new sponsor)
• Upgrade various OCP clusters to latest 4.18 minor version
• debug a acme renew issue
• Investigate crashing postgres on cbs-hub
• Degraded RAID array in sponsored machine
• CentOS-Stream-GenericCloud-x86_64-10-latest.x86_64.qcow2.SHA256SUM is a zero byte file
• cbs command aborts on Fedora 44 due to missing CA bundle path
• [reminder] : reach out to new sponsor in South Africa

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker

• Change Set Review for F45
• Script improvement and feature addition (in-progress):
  • fix(orphans): handle alternative providers to eliminate false positives
  • Fixes #9841 – adds a release_type field to .composeinfo so we can tell Beta and Final releases apart.
• Regular Releng Operations
• Fedora 42 EOL Preps

AI

This is the summary of the work done regarding AI in Fedora.

• Testdays (the webapp we use for running…Test Days) has an MCP server now (not sure if it’s deployed in prod yet though) – work by Jaroslav Groma

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

• Executive summary: Python 3.15 and kmscon Changes landing caused some fallout, tool tech debt payoff / enhancement continues, most team members used Day of Learning for AI experimentation
• Two major Changes landed: Python 3.15 and kmscon consoles, various fallout from that:
  • CoreOS and IoT both broken by the kmscon change
  • Got on-the-fly keyboard layout changes added (important for openQA)
  • Kickstart installs broken by Python 3.15 change (sent a fix)
  • Various openQA test updates required for kmscon fixes
• openQA serial bug worked around, new packages now deployed to prod
• Tech debt repayment and new feature work continue on testdays, issuebot and blockerbugs
• Kparal continues to find bugs in Lenovo laptop support
• Work on ELN kernel gating got blocked by an unfortunate pre-existing design problem
• Worked with Cristian Le to get rpmdeplint pipeline updated so fixes from last ~year are in prod, it now runs in ~2 minutes instead of ~20
• Team did some AI agent / skills experimentation during Day of Learning

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

• `testing-farm` optimized runner option provided to `ci` and `atomic-desktops` organizations
• Regular runners capacity increased from 1 to 4 concurrent jobs
• Private Issues work is ongoing.

EPEL

This team is working on keeping Epel running and helping package things.

• Executive summary: 
• Completed archiving of EPEL 10.1
• Package maintenance across multiple Fedora and EPEL packages
• Quality work via bug reports and bodhi karma

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

• Final stretch prepping Flock materials – Fedora badge, livestream template, sponsor splash
• Progress being made on the F45 Wallpaper
• Emma gave a talk about the Fedora Design team at the Waterford office’s Fedora 44 Release Party last Wednesday

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 24, 2026 appeared first on Fedora Community Blog.

Introduction

Hi, I’m Aman, a software developer and open-source enthusiast who enjoys backend development, APIs, and building tools that are useful to others.

I recently started my Outreachy internship with the Fedora community, and this is my first blog as an intern. In this post, I want to share what my first two weeks have been like, what I’ve learned so far, and what I’m looking forward to in the next phase of the internship.

I’m working on the Fedora Release Schedule Planner API, a project focused on improving Fedora’s release planning workflow by moving away from older XML-heavy processes and strengthening the current FastAPI-based API through better tests, authentication, and infrastructure integration.

About the Fedora Community

Fedora is a global open-source community behind Fedora Linux and many related projects. People contribute in many areas, including packaging, infrastructure, design, documentation, testing, and release engineering.

One thing I’ve enjoyed learning about Fedora is its Four Foundations: Freedom, Friends, Features, and First. These values reflect Fedora’s focus on free and open-source software, community, innovation, and adopting new technologies early.

What I like about Fedora is that it is not only about writing code. Communication, documentation, reviews, and helping new contributors are also important parts of the community.

Through this internship, I’m also getting a better understanding of Fedora’s release process and how different contributors work together to improve the tools used by the community.

About My Project

My Outreachy project is Enhancing the Fedora Release Schedule Planner API.

Fedora’s traditional release planning workflow relied heavily on manually edited XML files, which made the process difficult for newcomers, harder to scale, and less connected to modern tooling.

The Fedora Release Schedule Planner API is a modern FastAPI-based project hosted on Codeberg. It has already moved from Flask to a modular FastAPI architecture, uses Pydantic for data validation, provides auto-generated Swagger documentation, and relies on Forgejo Actions for CI/CD testing.

The goal of my internship is to help make this API more production-ready. My work will focus on improving the test suite, strengthening CI reliability, adding secure authentication with OpenID Connect, integrating the API with Fedora infrastructure data, and preparing it for deployment.

Learning More About the Community

I had already started contributing to the Fedora Release Schedule Planner API during the Outreachy contribution period. During that time, I joined the project’s Matrix chat, went through issues and pull requests, and became familiar with the basic project structure.

So, during the first two weeks of the internship, my focus was more on understanding the project in depth. I followed discussions in the Matrix chat, worked through issue and pull request conversations, and learned how mentors and maintainers review changes.

We also have a weekly Google Meet call with the mentors. These calls are helpful for discussing progress, asking questions, and understanding what to focus on next.

Alongside exploring the codebase, I spent time reading Fedora documentation and project-related resources to better understand the release planning workflow.

I also explored the FastAPI codebase, tests, CI setup, and previous pull requests more closely. This helped me understand how tools like Pydantic, Swagger documentation, and Forgejo Actions are being used in the project.

Challenges and Wins

One of my biggest challenges in the first two weeks was understanding the codebase beyond its basic structure. During the contribution period, I had already become familiar with the main parts of the project, but during the internship, I started understanding how different layers work together, including API routes, database models, Pydantic schemas, services, templates, and tests.

Another challenge was making sure my changes did not affect existing behavior. I had to run tests, check formatting, and verify things locally before updating a pull request.

My biggest win was becoming more confident with the project workflow. I was able to work on issues, raise pull requests, respond to review feedback, and understand the expectations around code quality and maintainability.

I also became more comfortable with the tools used in the project, including FastAPI, SQLAlchemy, Pydantic, Jinja2, HTMX, tests, and CI checks.

A small win for me was getting some of my pull requests merged. For example, PR #425 and PR #427 helped me understand the review process better and gave me more confidence while working on the project.

Plans for the Next Month

In the next month, I want to continue building on the work from the first few weeks. Currently, we are focusing on fixing UI-related issues, improving the code structure, and aligning the codebase with the project’s expected structure.

Along with that, I want to keep improving the test suite and make sure the API works correctly with the current FastAPI and Pydantic structure.

I also want to start preparing for the authentication part of the project. Since OpenID Connect is an important goal of this internship, I plan to spend time understanding how Fedora authentication works and how it can fit into the Release Schedule Planner API.

After that, I want to gradually learn more about how this API can connect with Fedora infrastructure data. This is important because the long-term goal of the project is to move away from the older XML-based workflow and make the release planning process more modern and maintainable.

Conclusion

These first two weeks have helped me understand the project better. I now have a clearer understanding of the Fedora community, the Release Schedule Planner API, and how people collaborate in open source.

I still have many things to learn, but I feel more comfortable with the project now than I did at the beginning of the internship.

I am thankful to Outreachy, Fedora, and my mentors for this opportunity, and I am looking forward to continuing the work in the coming weeks.

PS: Cover image generated with the help of an AI tool.

The post From Contributor to Outreachy Intern: My Fedora Journey Begins appeared first on Fedora Community Blog.

The F44 election cycle has concluded. Below are the results. We are posting the results early this year as we are currently on the eve of Flock to Fedora 2026 and the results were ready. Thank you to all candidates and voters, and congratulations to the newly elected members!

Results

Council

Two Council seats were open this election. A total of 204 voters participated in this election.

FESCo

Five FESCo seats were open this election. A total of 199 voters participated in this election

Mindshare

Four Mindshare seats were open this election. A total of 154 voters participated in this election.

EPEL Steering Committee

Four EPEL Steering Committee seats were open this election. As the amount of interviews submitted equaled the number of open seats, candidates who interviewed were automatically elected.

The post F44 Election Results appeared first on Fedora Community Blog.

We, the Forge team, recently onboarded a Codeberg-hosted repo to the new Fedora Konflux instance.
This is a guide based on the onboarding experience, the steps and UI are similar in Fedora’s Forge.

Useful links

• Konflux UI: https://konflux-ci.fedoraproject.org
• Documentation: https://konflux-ci.dev/docs/
• Cluster Console: https://console-openshift-console.apps.kflux-fedora-01.84db.p1.openshiftapps.com
• Cluster API (for oc login): https://api.kflux-fedora-01.84db.p1.openshiftapps.com:6443

Step 1: Get access to the tenants-config GitLab repo

Konflux configuration is managed through GitOps in the
tenants-config
repo on GitLab. The UI is intended to be read-only — you should do everything through merge requests.

• Sign in via SAML SSO at https://gitlab.com/groups/fedora/-/saml/sso to get
  group membership.
• Make sure you have at least a Guest role. Guest lets you approve MRs
  but not merge them. Ask a maintainer to bump your role if needed.
• Get yourself added to CODEOWNERS for your tenant’s directory
  Example MR.

Step 2: Create your tenant namespace

Follow the instructions in the
tenants-config repo:

• Run the create-tenant-resources playbook. It generates the namespace, RBAC
  and quota resources.

You end up with three files:

• ns.yaml — the namespace with a konflux-ci.dev/type: tenant label
• rbac.yaml — a RoleBinding granting konflux-admin-user-actions to your FAS
  user
• kustomization.yaml — ties together the quota, RBAC, namespace and your
  applications directory. Quota can be increased later.

Then run the update-tenant-apps playbook to generate an ArgoCD application
manifest per tenant directory and update the ArgoCD kustomization.

Example MR.

Step 3: Define your Applications and Components

This is where you tell Konflux what to build. We went with a Kustomize
Configuration-as-Code setup with three layers:

• A shared base — a generic Component template with the git URL, provider
  annotations (git-provider: forgejo, git-provider-url: https://codeberg.org),
  pipeline config and the build.appstudio.openshift.io/request: configure-pac
  annotation.
• Per-application bases — an Application CR plus per-variant overrides (e.g.
  rawhide vs. stable).
• Per-environment overlays (staging/production) — patches for application names,
  component names, context paths and Dockerfile paths.

Open a merge request with everything
Example MR.

Step 4: Add ImageRepository resources

Each Component needs a matching ImageRepository CR. If you don’t have one, the image controller
never provisions a Quay repo, spec.containerImage stays empty on the
Component, and the build service just sits there waiting. No webhook, no PaC PR,
nothing happens.

Example ImageRepository:

apiVersion: appstudio.redhat.com/v1alpha1
kind: ImageRepository
metadata:
  name: forge-rawhide-production
  namespace: fedora-infra-tenant
  annotations:
    image-controller.appstudio.redhat.com/update-component-image: "true"
  labels:
    appstudio.redhat.com/application: forge-production
    appstudio.redhat.com/component: forge-rawhide-production
spec:
  image:
    name: fedora-infra-tenant/forge-rawhide-production
    visibility: public

The update-component-image: "true" annotation is what tells the image
controller to write the Quay URL back to spec.containerImage on the Component.

Example MR. Do not merge yet.

Step 5: Create the SCM secret

Konflux needs a secret to authenticate with your Forgejo/Codeberg instance:

oc create secret generic pipelines-as-code-codeberg 
  -n {namespace} 
  --type=kubernetes.io/basic-auth 
  --from-literal=password={FORGEJO_TOKEN}

oc label secret pipelines-as-code-codeberg -n {namespace} 
  appstudio.redhat.com/credentials=scm 
  appstudio.redhat.com/scm.host=codeberg.org

The Konflux docs
say you need these token scopes:

• issue: Read and Write
• organization: Read
• repository: Read and Write
• user: Read

Don’t restrict the token to a specific repo — scopes like write:user aren’t
available with repo-scoped tokens on Forgejo. If you set the right scopes and
it still complains about insufficient permissions, try a token with everything
enabled.

Step 6: Merge and verify

With the secret in place, merge your MR. ArgoCD picks it up and syncs the
resources. Wait a few minutes, then check:

# Did containerImage get set?
oc get components -n {namespace} 
  -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containerImage'

# Are the ImageRepositories ready?
oc get imagerepositories -n {namespace} 
  -o custom-columns='NAME:.metadata.name,STATE:.status.state'

# What does the PaC status say?
oc get components -n {namespace} 
  -o custom-columns='NAME:.metadata.name,STATUS:.metadata.annotations.build.appstudio.openshift.io/status'

If spec.containerImage is filled in and the status shows "state":"enabled",
you’re good.

Step 7: Handle the PaC pull requests

At this point Konflux opens PRs on your source repo with auto-generated Tekton
pipeline files in .tekton/. Two ways to go:

• Merge them as-is if you’re happy with Konflux’s defaults.
• Close them and use your own pipelines. If you already have .tekton/ files,
  update them with:
• application/component labels matching your Konflux component names
• output-image pointing to quay.io/redhat-user-workloads/{namespace}/{component}
• latest task bundle versions (grab the @sha256:... refs from the
  Konflux-generated files)
• serviceAccountName: build-pipeline-{component}

We went with the second option. We already had pipelines with custom version
tagging that we wanted to keep, so we pulled in the new task bundles and labels
from the generated files and left the rest alone.

Step 8: Re-triggering when things go wrong

The configure-pac annotation gets consumed on the first attempt. If it fails
(token issue, rate limit, whatever), you need to re-add it:

# One component
oc annotate component {component} -n {namespace} 
  build.appstudio.openshift.io/request=configure-pac --overwrite

# All of them
for comp in $(oc get components -n {namespace} -o name); do
  oc annotate $comp -n {namespace} 
    build.appstudio.openshift.io/request=configure-pac --overwrite
done

To sum it up, we created a tenant on Konflux-ci cluster, created applications and components and set a place where the images would be hosted. At the event of push to the codeberg repo main branch – the repo where we store the Forge Containerfiles, the pipeline gets triggered (scoped by the on-cel-expression to only those contexts where the change happened) and a fresh and tagged image appears on quay, ready for further testing and deployment.

Thanks to the Konflux Team for the Forgejo support!

The post Onboarding a Forgejo-hosted project to Fedora Konflux appeared first on Fedora Community Blog.

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 01 – 05 June 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

• Devise the flagging of inactive badges as a boolean column [Triaged]
• feat: add legacy boolean column to badges [Approved]
• Add unit tests for _serve_frontend path traversal safety [Suggested]
• Add (or modify) methods to filter/modify the legacy status [Triaged] [Followup]
• Moved fedora-badges to badges-assets [Repository] [Followup]
• Mark the Pagure’s Fedora Badges repository as OBSOLETE [Commit] [Followup]
• Revamp Fedora Badges Project (into develop) [Merged]
• Port the project management aspect from Poetry to UV [Triaged A] [Triaged B]
• Refreshed the Fedora Badges staging deployment [Resource]
• Update badge rarity calculation [Reviewed] [Followup]
• Modularize the dbapi module while retaining the references [Followup]
• feat: normalize tags into separate tables [Review A] [Review B]
• Readme.md file update [Closed] [Followup]
• Update badge rarity calculation [Review A] [Review B]
• rhel10 migration: tang servers
• rhel10 migration: memcached instances
• nftables cleanup, and table rename
• discover why proxy11 struggles with restarting apache

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• Sho-Me Power: CentOS Stream Mirror request
• Multiple rsync upstreams are serving stale content

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

• F44: core rebuild is completed. Image generation and repo-creation needs some work. ‘omni’ kernels are being built and  ‘kiwi descriptions’ (required for image generation) needs some RISC-V specific patching.  We’re short on resources , so this delay is expected.
• Conferences preparation:
  • Prep for RISC-V Summit, meetings with hardware vendors, upstream meetings, and RISE 
  • Prepare updated material for Flock RISC-V update
• [Hardware] We have one of the newest RVA23 boards (SpacemiT K3) in Fedora RISC-V Koji.
  • Thanks to Jason Montleon.  It’s his personal hardware.   A CLE-sponsored Fedora K3 builder is on its way to him too, it’ll be wired into RISC-V Koji
• [Hardware] Discussed with Jefro about potentially working with Scaleway to get some cloud builders via the RISE initiative.  To be discussed at the RISC EU Summit.

AI

This is the summary of the work done regarding AI in Fedora.

• t0xic0d3r helped draft the Fedora AI Developer Desktop Community Objective logic model [Draft]

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

• Reported bugs related to Thinkpad X1 Carbon Gen14, a laptop that could be in the next laptop models offering for RHatters. Both the microphone and camera are broken. Notified the CSB team and Mark Pearson from Lenovo.
• We missed an installer crash in F44 KDE and other spins (but not Workstation), documented it and took follow-up steps to prevent it in the future. We have flagged before that having multiple installer UIs and storage paths raises the risk of this kind of situation
• Ongoing tool tech debt and enhancement work: reviving and fixing issuebot, MCP server and devcontainer config for testdays-web, cloud automation now reporting to resultsdb
• cloud automation found systemd bug at AWS
• openQA: deployments upgraded to Fedora 44 and new os-autoinst packages, fedora-media-writer coverage extended, discovered multiple dependency bugs, dracut decryption bug, plymouth keyboard layout bug, KDE config panel layout bug

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

• Discussed the coordination process for the private issues
• Enabled the members team to create repositories [Access]

EPEL

This team is working on keeping Epel running and helping package things.

• Prepared EPEL 10.1 for move to archives
• Package maintenance across multiple Fedora and EPEL packages
• Quality work via bug reports and bodhi karma
• Starting to onboard Pedro

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

• Finalizing Flock materials
  • Everything for print sent to organisers
  • Digital assets is now the focus

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 23 2026 appeared first on Fedora Community Blog.

The F44 elections voting period is now open! The ballot boxes for this cycles elections are open from today, Monday June 1st until Friday, June 12th on the elections app. The ballot boxes will close on June 12th at 23:59:59 UTC.

For links to candidate interviews, please visit this post or the nominations wiki page of each election.

As the number of eligible candidates (4) equaled the number of open seats (4) for the EPEL Steering Committee, no ballot box is available for this election. Instead, these candidates are automatically elected by default.

Good luck to all of our candidates across Fedora Council, FESCo and Mindshare Committee during this election cycle!

The post F44 Elections Vote Now! appeared first on Fedora Community Blog.

The F44 election interviews are now live. With seats open across all leadership groups, this is one of our most popular election cycles yet! Use this post to navigate to candidates interview posts easily.

Voting will be open on Monday, June 1st and will close at 23:59 UTC on Friday, June 12th. Best of luck to all our candidates!

Fedora Council – 2 seats open

• Miro Hrončok
• Vít Smolík
• Akashdeep Dhar
• Aleksandra Fedorova
• Tomáš Hrčka
• Fabio Valentini
• Hristo Marinov

Fedora Engineering Steering Committee/FESCo – 5 seats open

• Adam Miller
• Maxwell G
• Neal Gompa
• Fabio Valentini
• Simon de Vlieger
• Michel Lind

Fedora Mindshare Committee – 4 seats open

• Mat Holmes
• Akashdeep Dhar
• Mackenzie Stewart
• Luis Bazan
• Samyak Jain

EPEL Steering Committee – 4 seats

• Diego Herrera
• Carl George
• Troy Dawson
• Jonathan Wright

The post F44 Elections Interviews appeared first on Fedora Community Blog.

This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Jonathan Wright (jonathanspw)

What is your name and what is your FAS ID?

Jonathan Wright, jonathanspw

What is your background in EPEL? What have you worked on and what are you doing now?

I’ve been a consumer of EPEL for…a long time. 20 years? I’ve been a contributor to EPEL for about the past 5, and on the EPEL steering committee for the past year.

EPEL is very near and dear to my heart and is actually how I got involved with Fedora. I’m on the AlmaLinux team and like everyone else, the first thing I do when installing AlmaLinux (previously CentOS) is dnf install epel-release. I’ve successfully graduated packages from EPEL that ultimately got picked up by RHEL (see Valkey) and work to make EL distros more usable by having an array of package availability that’s not otherwise available without EPEL.

Why are you running for EPEL Steering Committee member?

I have a unique perspective to bring to the table with my history in web hosting and long time usage of RHEL and its clones (CentOS and now AlmaLinux). The past year serving on the EPEL steering committee has been a great honor and I hope to continue in that role for another year.

The post F44 EPEL Elections: Interview with Jonathan Wright (jonathanspw) appeared first on Fedora Community Blog.

This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Diego Herrera (dherrera)

What is your name and what is your FAS ID?

• Name: Diego Herrera
• FAS ID: dherrera

What is your background in EPEL? What have you worked on and what are you doing now?

My relationship with open source started back in 2006, and I’ve been an
advocate since, both by contributing to various projects and by publishing
my own. My deep dive into EPEL began in 2013 while working in a company doing
R&D work for local industries, where I gained my first practical
experience with RPM packaging. This early work gave me a solid understanding
of what it means to build and manage software within the Enterprise Linux context.

More recently, I joined Red Hat in 2021 to work as part of the
CLE Team, where I deepened my understanding of how to become a proper Fedora packager
and contributor. I have been working together with Carl George, focusing on the
needs of EPEL by participating in steering meetings and doing work
regarding the project’s infrastructure. Through this position, I was able to
participate in activities such as packaging, writing documentation and SOPs,
collaborating on maintenance work required for the infrastructure, and improving
infrastructure automation. Furthermore, during steering meetings, I have been able to
add my viewpoints and insights when they were needed, and I was also able to
take on some of the steering team’s workload,
such as the Forgejo migration.

Why are you running for EPEL Steering Committee member?

Over the last few years, while spending time on the infrastructure side of the project,
I’ve seen first-hand the ups and downs of the project, which has enabled me to
collaborate closely with members of the community.

The EPEL steering committee is already a place where I have been able to
use my experience and knowledge to support and contribute to the project.
However, this time I want a vote on these topics. This will allow me to
collaborate further, helping to turn those discussions into a better
path for the project. I want to continue helping the community so
that the project can continue to grow into a great
platform by ensuring our governance is as solid and reliable as our processes.

For the sake of transparency, even if I wrote the text myself, I also used a local LLM (Gemma4:e4b) to iteratively fix the text’s grammar and flow.

The post F44 EPEL Elections: Interview with Diego Herrera (dherrera) appeared first on Fedora Community Blog.

This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Carl George (carlwgeorge)

What is your name and what is your FAS ID?

• Carl George
• @carlwgeorge
• Fedora wiki page

What is your background in EPEL? What have you worked on and what are you doing now?

I got my start in Fedora and EPEL in 2014. I was working for Rackspace and joined a team whose primary purpose was to maintain IUS, a third-party package repository for RHEL. Part of my work there involved contributing to and maintaining EPEL packages. I left Rackspace in 2019 to join the CentOS team at Red Hat. In 2021, I started a new team at Red Hat to specifically focus on EPEL activities.

During my time on the EPEL team, I’ve lead the design and implementation of EPEL 9 and EPEL 10. These releases each brought significant improvements to packager workflows and user experience, especially the introduction of minor versions in EPEL 10. We’re currently in the early days of planning EPEL 11, with a focus on continued refinement and quality.

Aside from the hands-on technical work of EPEL release engineering and packaging, I routinely attend conferences to deliver presentations about EPEL and staff Fedora/CentOS booths to engage with the EPEL community. I enjoy mentoring new packagers and helping existing Fedora packagers get started with EPEL.

Why are you running for EPEL Steering Committee member?

I have been on the EPEL Steering Committee since 2020. I have enjoyed my six years serving on the committee, and hope to have the opportunity to continue this important work. I am passionate about EPEL and I am committed to continue finding ways to improve the EPEL experience for both packagers and users.

The post F44 EPEL Elections: Interview with Carl George (carlwgeorge) appeared first on Fedora Community Blog.

This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Troy Dawson (tdawson)

What is your name and what is your FAS ID?

Troy Dawson (tdawson)

What is your background in EPEL? What have you worked on and what are you doing now?

I started contributing to EPEL 11 years ago with some nodejs packages for OpenShift. I later added rubygems and golang packages as OpenShift changed languages. Later, RHEL 8 did not have KDE, so I added KDE to epel8, and have been maintaining KDE in epel ever since. I have picked up many other packages during the years, but I think my KDE contributions are what I am most known for.

I’ve been the EPEL Steering Committee chair since 2020, taking over from Stephen Smoogen. A lot of changes have happened since then, most of them for the better. I’m not responsible for all the changes, but it’s been wonderful being part of the committee as these changes have come through.

Why are you running for EPEL Steering Committee member?

EPEL has grown to be part of my professional and personal life. I not only want to contribute to it, but help steer it’s growth and progression. I think as a EPEL Steering Committee member, I can help keep EPEL healthy and thriving.

The post F44 EPEL Elections: Interview with Troy Dawson (tdawson) appeared first on Fedora Community Blog.

This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Akashdeep Dhar (t0xic0der)

• FAS ID: t0xic0der
• Matrix Rooms: Fedora Council (#council:fedoraproject.org), Fedora Mindshare (#mindshare:fedoraproject.org), Fedora Forgejo (#fedora-forgejo:fedoraproject.org), Fedora Infrastructure (#admin:fedoraproject.org), Fedora Badges (#badges:fedoraproject.org), Fedora Apps (#apps:fedoraproject.org), Fedora Join (#join:fedoraproject.org), Fedora Mentoring (#mentoring:fedoraproject.org)

Questions

What is your background in Fedora? What have you worked on and what are you doing now?

Since the past year, I have been actively contributing to the event planning [1] [2] and proposal curation in the Mindshare committee. Representing our vested interests in the Fedora Council, I have paved the way for improvements in the regional event support (i.e., event owners and regional inventory), digital ambassadorship (i.e., swagpack designs and social media) and recognition service (i.e., Community Metrics and Fedora Badges).

Besides championing our community presence in underrepresented regions (e.g., in DevConf.IN 2026 and FOSSAsia 2026 in APAC), I have continued staying at the forefront of the Fedora Forge community initiative, working as an infrastructure architect for Fedora Infrastructure applications, organizing Fedora Mentor Summit during Flock events and mentoring budding contributors formally/informally in the community.

Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare

Technology might be why I joined the Fedora Project, but I stayed because of the people who made me feel at home. Progressing in various aspects of our planned functions over the past years has taught me one crucial thing – contributors are actually retained when they feel noticed, supported and trusted with meaningful work. The Mindshare Committee is where that happens, and I want to keep building what we started.

Furthermore, as the committee’s representative to the Fedora Council, I have seen firsthand how decisions at the governance level shape the contributor experience on the grassroots level. The update during the Fedora Council Strategy Summit 2026 gave us an opportunity to serve event organizers, community ambassadors and voluntary contributors better, all while using these outcomes to enhance the community health.

How would you improve Mindshare Committee visibility and awareness in the Fedora community?

Simple. We need to show up where the community is. A community booth in one event, some interactive workshops in another – to begin with in regional event support to ultimately show people that we indeed care. While making sure that our infographic swagpacks are updated on a regular basis in digital ambassadorship, we actually ensure that we are providing people with reasons to come back to us when the time is right.

With the upcoming collectible rarity feature in Fedora Badges and tangible contributor recognition awards (both as a part of Fedora Mentor Summit event and separately), we nudge people to more opportune contribution avenues while avoiding burnouts in longtime contributors. This could further be extended to our Fedora Linux Release Parties too, as ultimately, most of our community members started off as its users.

What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?

Contributor Recognition. With over half a decade of experience in this space, the “What now?” problem (after the first contribution) has only become worse with the advent of AI Assisted Contribution Activities. Newcomers struggle to realize the value proposition of the community connection that Fedora Project could provide, and hence, it has become the need of the hour to incentivize contributions using rewarding activities.

But apart from that, we also need to do better at further improving our local presence in underrepresented regions. In this past term, my pilot experiment on APAC events worked wonders, and it showed us all the community power we can tap into by just being there. With reusable swagpacks, localized printing, active conversations and documented accounts, this limited experiment can scale well across various parts of the globe.

The post F44 Mindshare Elections: Interview with Akashdeep Dhar (t0xic0der) appeared first on Fedora Community Blog.

This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Mackenzie Stewart (monkeybean12)

• FAS ID: monkeybean12
• Matrix Rooms: I tend to use these Matrix channels, Fedora, Fedora EPEL Matrix, Announcements, Introductions.

Questions

What is your background in Fedora? What have you worked on and what are you doing now?

My background in Fedora is using the Java programming language from Oracle and I have worked on games and graphics with Java language. I am currently writing computer programs for other computer languages which are Python, JavaScript in nodeJS and Building/Maintaining WordPress websites using PHP, HTML5 and CSS3.

Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare

I want to help bring people together and support the culture around Fedora, not just the technical work. Fedora is more than just an operating system to me — it’s a community. I want everyone who contributes, whether they code, design, or help run events, to feel valued and know their work matters.

How would you improve Mindshare Committee visibility and awareness in the Fedora community?

I would propose a recurring, informal ” Monthly Community News” session—open to all—where Mindshare members discuss why certain decisions were made, rather than just reporting the results. Also to be a place for any updates or events to be introduced or announced so that it may generate more interest to all.

What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?

Mindshare should act as the “connective tissue.” I want to focus on creating a standardized, project-wide mentorship framework that assists sub-projects in bringing in new contributors.

The post F44 Mindshare Elections: Interview with Mackenzie Stewart (monkeybean12) appeared first on Fedora Community Blog.

This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Mat Holmes (theprogram)

• FAS ID: theprogram
• Matrix Rooms: Join, Fedora, Fedora Social, DEI, Mindshare, Design, Council, CommOps, Server, Docs. I also monitor technical channels, but try not to distract people there too much.

Questions

What is your background in Fedora? What have you worked on and what are you doing now?

I started with Fedora through Discussion, our Fedora Help Desk. This helped me both learn and teach about Fedora.
Once I found Matrix, I quickly got involved as a member and sponsor with Join, where I to this day very much enjoy meeting and welcoming many new people.
As I continued over the past couple of years, I have progressed to many people facing roles such as helping with DEI and CommOps. I also stick my beak into Mindshare and Council topics while trying to not step on peoples toes.
These days I have started writing Docs such as the Beginners Guide to Fedora and I am now helping with Server where we are developing new Beginners Guides to Server and the upcoming Home Lab.

Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare

Mindshare suites me very well as I have extensive experience organising events and doing outreach for professional organisations such as Amnesty International Australia and a political party (which I won’t name as politics is too divisive – but feel free to ask me about it).

My personal motivation is that I enjoy working with people in the Fedora community.

How would you improve Mindshare Committee visibility and awareness in the Fedora community?

The role of Mindshare has changed over the last couple of cycles to be more focussed on events. I would promote people to talk early and often to us, so we can put more smaller events on the table.

What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?

I think Mindshare needs a clearer idea of what budget we have to work with, and we need faster responses to ticketed issues.
We also need to improve the accessible roads to ambassadorship, both in person and digital. Taking my skills from Join, I would extend this to being available to help plan broader small group involvement with communities all over the globe.

The post F44 Mindshare Elections: Interview with Mat Holmes (theprogram) appeared first on Fedora Community Blog.