This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 25 Aug – 29 Aug 2025
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 18 Aug – 22 Aug 2025
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
Hi, I am Mayank Singh, welcome back to this blog series on the progress of the new package submission prototype, if you aren’t familiar with the project, feel free to check out the previous blogpost here.
Extending Forgejo support
As Forgejo is expected to become the git forge for Fedora in future and based on community discussions. I thought it did be great to support Forgejo in this project.
packit-service supports both GitLab and GitHub thanks to OGR library. It provides a unified interface for interacting with git forges. The library has a good support for GitHub and GitLab features but the Forgejo integration is still not quite on par with them, few important functions like adding comments and reactions are still missing. I worked on adding the support for the necessary parts so that packit-service can work with Forgejo. There are few bugs related to serialization in the code, which I plan to fix this week.
New Package Builds from New Pull Requests
I’ve added a simple handler to read from a new Pull Request and its description to parse packit commands. This allows users to trigger a build for a new package without needing a packit configuration file in the repository.
For example, adding this line the PR description will trigger a new build for this particular package name.
/packit copr-build package_name: <libexample>
The system dynamically constructs a minimal package config and feeds it into Packit’s internal build logic. Test jobs are expected to work as well, although this is yet to be fully verified.
The current implementation is a quick prototype that reuses as much of the existing packit-service logic as possible. There’s still more work to be done around building the full package context. My mentor has also shared feedback suggesting a cleaner approach, which I’ll be iterating on in the next phase.
What’s Next?
Fix remaining serialization bugs.
Build and test the Testing Farm integration for running test jobs on the built packages.
Improve the source handling logic based on recent feedback.
Thanks for reading and stay tuned for more next week.
This week in the project involved bug fixes, integration cleanup and small improvements.
Bug Fixes and Workarounds
A key function required for the Forgejo integration which is used to fetch files from repositories was broken in the current Fedora 42 release due to an upstream bug in Forgejo’s OpenAPI spec. While the bug is already fixed in newer versions, it couldn’t be backported cleanly due to dependency constraints.
To move forward, I upgraded the service to run on Fedora Rawhide. However, Rawhide had its own quirks, the celery package was broken. To work around this, I installed celery directly from PyPI instead, which resolved the issue for now.
There were also several issues related to how data was being passed between the celery tasks. In particular, raw comment objects from Forgejo events were being passed around, which are not JSON-serializable and caused failures. With help from my mentor, added fixes in the logic to ignore the problematic object from being included in the payload.
Improvements and features
Enabled the `fedora-review` tool for all COPR builds in the codebase by monkey-patching the API call to enable fedora-review, which is not available directly otherwise from the packit API. This allows us to get a list of tasks and requirements for Fedora packaging compliance for the corresponding build of the package.
As of now, COPR builds and testing of the builds work. I started working on status reporting, it’s still rough, and I attempted to get comments working, but I’ll need to add more support in the OGR library to implement commit status properly.
As part of my Outreachy internship with the Fedora Project, I’m building an API to modernize how Fedora plans its release cycles.
With the help of my mentor Tomáš Hrčka, the goal is to replace the current XML-heavy system currently on pagure.io with something flexible, easy to use, and well-structured.
These changes already make onboarding contributors easier and improve testability.
What’s Next
I’m excited about these upcoming milestones:
Refining and aligning tests with the FastAPI structure.
Integrating with Fedora infrastructure for live data.
Strengthening the deployment pipeline for production.
Challenges
My biggest challenge and opportunity is simultaneously learning new backend technologies like FastAPI and OpenID Connect for authorization, along with techniques to improve developer onboarding. Though the learning curve is steep, my mentor’s continuous guidance on the Fedora infrastructure, career development and general advice makes it manageable.
Reflections
This internship has been an incredible learning experience. I’m gaining hands-on exposure to backend architecture, continuous integration practices, and open-source collaboration. More importantly, the chance to build something lasting for Fedora makes the work genuinely rewarding.
There’s a lot left to tackle, and I’m looking forward to pushing it further.
Koji is unavailable during F43 mass branching for external users. All builds
that will be running at that time for the rawhide will be canceled and can
be resubmitted by maintainers after the branching.
Once Fedora Linux 43 is branched we will reenable builds in Koji.
The man command, is short for manual. It provides access to the various up-to-date on-board documentation pages. This helps users utilize the Linux/Unix operating systems in a better manner.
What is man ?
The man command is a manual pager which provides the user with documentation about specific functions, system calls, and commands. The man command uses the less pager by default. (See man less for more information.)
Note that a man page is likely to contain better up-to-date information compared to what can be found on the internet. It is wise to compare the man page usage and options with that found on the web.
How to use man ?
To use the man command effectively we have to know the manual pages system. The manual pages are distributed in 8 sections. Each provides documentation on particular topics.
What are the manual page sections ?
Programs, shell commands and daemons.
System calls.
Library calls.
Special files, drivers, and hardware.
Configuration files.
Games.
Miscellaneous commands.
System administration commands and daemons.
Examples
To get the printf library function documentation (section 3):
# man 3 printf
To get the printf shell builtin documentation (section 1):
# man 1 printf
You can learn more about the man command and its options:
# man man
How to manage the index caches database
To update the existing database, or to create it, use the -c or –create flag with the mandb command:
# mandb --create
To do a correctness check on the documentation database use the -t or –test flag:
# mandb --test
How to export manual pages
To export a man page, use the -t flag with the man command:
man -t 5 dnf.conf > manual.ps
This will create a PostScript file with the contents of the dnf.conf man page from section 5.
Alternatively, if you want to output a PDF file, use something like this instead:
man -Tpdf 5 dnf.conf > dnf.conf.pdf
You will need the groff-perl package installed for this command to work.
Summary
The need to get information about commands, daemons, shell builtins, etc. to make them do what they are intended to do correctly, motivates us to use the system manual to learn not everything but the required knowledge to reach our goal.
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 04 Aug – 08 Aug 2025
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
Join us to test the 6.16 kernel for Fedora Linux 43 during August 10 – 16!
What is a test week?
Test weeks are organised by the Fedora QA team per release cycle and are a great way to get involved in developing the upcoming Fedora Linux release. Instructions and test cases are provided for you, plus you will also be mentioned and thanked in the ‘Heroes of Fedora‘ blog at the end of the release. For more information on how to get involved, check out the Fedora Test Days wiki, and to participate in the upcoming Kernel 6.16 test week, read on!
Kernel 6.16 Test Week
The kernel team is working on final integration for Linux kernel 6.16. This recently released kernel version will arrive soon in Fedora Linux. As a result, the Fedora Linux kernel and QA teams have organized a test week from Sunday, August 10, 2025 to Saturday, August 16, 2025.
The wiki page contains links to the test images you’ll need to participate. The results can be submitted in the test day app.
What are we looking for?
Regressions when rebasing
Issues when installing from USB on VM and/or bare metal systems (file under ‘exploratory)
What do I need to do?
To contribute, you only need to be able to do the following things:
Join us this week for the Anaconda Web UI Installer test week where we are focusing testing on Anacondas brand new WebUI for KDE and Spins live images.
What is a test week?
Test weeks are organised by the Fedora QA team per release cycle and are a great way to get involved in developing the upcoming Fedora Linux release. Instructions and test cases are provided for you, plus you will be mentioned and thanked in the ‘Heroes of Fedora‘ blog at the end of the release. More information on how to get involved is located on the Fedora Test Days wiki. To participate in the upcoming Kernel 6.16 test week, read on!
Anaconda Web UI Installer Test Week
The Anaconda WebUI became the default installer interface in the previous Fedora release for Fedora Workstation. This Test Day extends that effort to ensure the WebUI works smoothly across the broader Fedora ecosystem, especially in various Spin environments and Fedora KDE. As a result, the Anaconda and QA teams have organized a test week from Monday August 4, 2025 to Friday August 8, 2025.
The wiki page contains links to the test images you’ll need to participate. The results can be submitted in the test day app.
What are we looking for?
How partitioning is working
Cockpit Storage Editor performance
Internalisation
Issues not mentioned in the test cases – file those findings under ‘exploratory’.
What do I need to do?
To contribute, you only need to be able to do the following things:
July is already behind us – time really flies when you’re learning and growing! I’m happy to share what I’ve been up to this month as a Fedora DEI Outreachy intern.
To be honest, I feel like I’m learning more and more about open source every week. This month was a mix of video editing, working on event checklists, helping with fun Fedora activities, and doing prep work for community outreach.
Shoutouts
First, I want to say a big thank you to my mentor, Jona Azizaj, for her amazing support and guidance.
Also, shoutout to Mat H (the program) – thank you for always helping out and making sure I stay on track.
Being part of the Fedora DEI team has been a really positive experience. It feels awe-some to be part of the team.
What I’ve been working on
Event Checklists
I reviewed the existing event checklist and started making updates to improve it. I want to make it easier for future organizers to plan Fedora events. If you haven’t checked it, you can find the draft in the Discourse post and be sure to leave your comments if you have something to add.
How I managed swags and funding
This month, I figured out how Fedora handles swag distribution, event funding, and reimbursements through ticket requests and Mindshare support – especially useful for local events like mine in June. I’m documenting the process to make it easier for future contributors to plan events smoothly.
Video editing
I worked on editing Fedora DEI and Docs workshop video, which will be used to promote our work. Actually I didn’t know anything about editing, but it’s worth editing this to learn a few things about video editing.
Fedora Fun Activities
I’ve taken over the Fedora Fun socials! We hosted a social session on July 25 at 15:00 UTC, and another one followed on Friday, August 1. These are light, 1-hour sessions to hang out with our community members.
I’ve also started working on community outreach, you can check this discourse post, a draft for what I am looking forward to, helping prepare for future Fedora outreach within our regions, especially around how to reach out to students, what topics would be covered and more.
Chairing DEI Meetings
I got the chance to chair multiple Fedora DEI team meetings. It felt a bit scary at first, but with each meeting, I’ve become more confident running the meetings and helping keep things on track.
It helped me understand more about being inclusive when working with others – super helpful in open source communities!
What’s next
As we move into August, our main focus will be:
Community Outreach – bring more people into Open Source and Fedora’s space.
Event Checklist Documentation – we’re working on getting the updated checklist into Fedora DEI Docs so it’s more accessible and useful to everyone planning an event soon.
I’ll also continue contributing to DEI docs and helping organize fun and inclusive Fedora activities.
You’ve got anything we can do together? Hit me up on the matrix (username: lochipi) about it.
Final thoughts
This internship continues to teach me how open source works – from collaboration, planning events, to working with different Fedora teams.
If you’re curious about Fedora or want to support DEI work, join us in the Matrix room – we’d love to have you around.
Architects depend on digital tools for every stage of design, from sketching to modelling and documentation. But many popular tools are expensive, closed-source, or limited to specific platforms.
Fedora offers a fast, stable, and open environment for professional design work. With a growing ecosystem of free and open source software, architects can build a complete work-flow on Fedora, without sacrificing capability or control.
As an architect, I’d like to introduce how we can use Fedora for architectural design.
Fedora as Design Platform
Fedora Workstation is a solid choice for creative professionals. It is fast, up to date, and well-supported on a wide range of hardware, including laptops commonly used in architecture, like ThinkPads.
Fedora gives you access to a wide selection of open source applications through DNF, Flatpak, and COPR. Whether you’re installing stable packages or testing the latest versions, Fedora’s software ecosystem is flexible and developer-friendly.
With Wayland by default, good pen tablet support, and modern graphics drivers, Fedora handles demanding design tasks smoothly. It is a platform that gets out of the way, letting you focus on your ideas.
Open Source Tools for Architectural Design
Fedora supports a wide range of open source applications that can cover every stage of the architectural design process. From early sketching to 3D modelling, documentation, and even BIM. The following are some tools I use in practice.
Sketching and Early Concepts
Early-stage design relies on speed, intuition, and flexibility. On Fedora, you can use Krita for freehand sketching and expressive form exploration. Its brush engine and tablet support make it feel natural, especially when working through visual ideas. For quick annotations or tracing over site plans, Xournal++ offers a fast and lightweight interface. When you need to build simple diagrams or zoning layouts, LibreOffice Draw lets you combine shapes and text easily. These tools support a fluid design process, helping you stay focused on ideas, not technical barriers.
Drawing, Modelling, and Visualization
As your design develops, modelling becomes a way to explore space, proportion, and materiality. On Fedora, Blender offers a robust environment for 3D modelling, rendering, and animation. You can build conceptual massing studies, detailed geometry, and even walk-throughs or camera animations to communicate spatial experience. Real-time rendering in Blender with the Eevee rendering engine and photo-realistic output using the Cycles rendering engine make it possible to move quickly from model to image or video.
For precise 2D drafting, QCAD provides a clean and efficient workspace. It is useful for early layout studies, plans, and diagrams where clear lines matter more than complex parametrics.
These tools help you move from form to image — and from image to motion — using an entirely open work-flow in the open source ecosystem.
Parametric and Algorithmic Design
Parametric design lets you build geometry through rules and relationships — making form more flexible and responsive. While visual tools like Grasshopper aren’t natively available on Linux, Blender offers a few promising options.
The Geometry Nodes system in Blender supports procedural modelling based on attributes, modifiers, and data flows. For a more Grasshopper-like experience, the Sverchok add-on brings node-based parametric design into Blender — allowing you to create complex structures with visual logic. You can learn more about Sverchok at https://nortikin.github.io/sverchok/
If you prefer scripting, Blender’s built-in Python API gives you full control for custom modelling and automation. While the ecosystem is still evolving, these tools offer a solid foundation for algorithmic thinking in open work-flows.
Building Information Modelling (BIM)
If you work with BIM, Fedora supports open source tools that follow open standards like IFC. FreeCAD includes an Arch workbench designed for architectural model modelling, with objects like walls, windows, and sections that carry semantic data. It also supports parametric editing and IFC export, making it suitable for early-stage modelling and coordination. You can learn more about FreeCAD BIM Workbench at https://wiki.freecad.org/BIM_Workbench/.
Bonsai, an add-on for Blender, brings IFC-based modelling and data editing into a powerful 3D environment. You can create, inspect, and modify BIM models directly in Blender, with full control over geometry and metadata — without relying on proprietary formats. You can learn more about Bonsai at https://bonsaibim.org/.
While open source BIM is still evolving, these tools already offer meaningful work-flows for concept modelling, coordination, and documentation — all while staying aligned with open data standards.
Graphic and Document Production
Architectural work involves more than modelling — it also requires clear visuals and well-structured documents. On Fedora, tools like Inkscape and GIMP help you produce diagrams, edit renderings, or refine presentation materials with full control over layout and image quality.
For documentation, LibreOffice offers a reliable suite for writing specifications, reports, and schedules. If you prefer more control over formatting, LaTeX gives you a structured way to produce professional documents — especially when precision and consistency matter.
These tools help you communicate ideas clearly, whether for clients, collaborators, or construction teams.
Fedora Tips for Architects
Flatpak vs DNF
Many design tools are available through both Flatpak and DNF. Use Flatpak when you want easy access to the latest versions and isolated environments (e.g., graphics software), and DNF when you prefer tighter system integration and package control.
Pen Tablet Setup
Fedora detects most pen tablets automatically. You can configure pressure sensitivity, button mapping, and input area through GNOME Settings > Devices > Stylus, or use CLI tools like xsetwacom or libinput for advanced tweaks.
Fonts and Typography
Fedora provides a wide selection of high-quality free fonts through its repositories. You can install additional font packages using dnf, or manually place fonts in ~/.fonts/ for user-level use — useful when working on design boards or documents.
Version Control with Git
Even for design files, Git can help track changes and back up your work. Use it for versioning .blend, .svg, .fcstd, or even LaTeX files. For larger binaries, consider using Git LFS or structured folder snapshots.
Conclusion
Architecture is about more than form, it’s about intent, structure, and the systems that support them. The same applies to the tools we use. Choosing open source is not just about avoiding cost; it’s a decision to work with transparency, adaptability, and long-term agency.
Fedora offers a platform where design and freedom coexist, where architects can shape their tools as much as they shape space. It may not have every convenience out of the box, but it gives us something more enduring: control over our work-flow, and a community-driven path forward.
Designing openly is not always the easiest path, but it may be the most honest one.
We are currently under DDoS affecting most of the fedoraproject.org services as it's affecting proxies and those are redirecting most of the traffic to other fedoraproject.org services.
This also affects authentication and obtaining kerberos tickets
Update: 17:00UTC: All services should be up and functional. Please let us …
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 28th July – 01st August, 2025
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
The Anaconda team have done some great changes over the last few Fedora Linux releasese. For Fedora Linux 43, they would like your help testing their latest changes – switching Anaconda installer to DNF5 and removing DNF modularity support from Anaconda.
With the help of the Fedora QA team, a number of test matrices have been created to help folks who can take part test the new features and provide their results.
What are we looking for?
We are looking for folks to test the following and file your results in the Test Days app:
Run some basic tests
Check that you can install repositories
Check what package sets are successful on install
Any other exploratory testing you would like to do!
A test week is an event where anyone can help ensure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.
To contribute, you only need to be able to do the following things:
Download test materials, which include some large files
Read and follow directions step by step
The wiki page for the Anaconda Installer has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test day web application. If you’re available on or around the days of the event, please do some testing and report your results.
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 21st – 25th July 2025
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 14 July – 18 July 2025
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
Hi, I am Mayank Singh, welcome back to this blog series on the progress of the new package submission prototype, if you aren’t familiar with the project, feel free to check out the previous blogpost here.
Event Handling, Forgejo Support, and Source Management (July 8 – July 15)
This week was focused on the service’s forge and tackling the challenge of source management.
Migrating to Forgejo and Handling Events
Based on community feedback, advantages and assessing our requirements, I moved the service’s forge to Forgejo. This minimal, open-source alternative to GitHub and GitLab is simpler to self-host and has significantly smoothed out our testing process.
On the implementation front, I added support for parsing issue and push events in packit-service, which allow to support parsing commands from issue comments. That being done adding support for pull_request is only trivial now and have a solid understanding of packit-service‘s event model to trigger task execution.
Package Source Handling
I hit a technical dilemma when considering handling the case of packages with new dependencies in a single Pull Request and handle their sources. The workflow requires accessing the PR’s diff, resolving it into individual files, and submitting those sources to be built in COPR.
My initial solution to this problem was to create a dedicated organization in Forgejo where every new package would get its own repository to store its sources. However, my mentor advised against this model, we discussed and realized it would become too complex and non-intuitive to work with. Instead, he clarified the path forward to focus on simple packages for now and investigate how Packit already solves this by cloning the source repository.
What’s Next?
Enhancing Forgejo Integration: Implementing methods to allow the service to post comments and add reactions on Forgejo.
Implementing Source Fetching: Building the logic to fetch source files from Pull Requests for package builds.
Expanding Commands: Adding new commands and tasks to support this workflow.
Hi everyone, I am Mayank Singh, currently working on a new service for simplifying the Fedora Package Submission Process, if you’d like to know more check my previous post here.
Diving Deep into Packit Service
(27 June – 8 July):
I began working on the packit-service codebase as the foundation for our project. The first goal was to prototype the user flow by creating new APIs and handlers for functionalities like detecting new packages and linting.
Pretty early on, I hit a roadblock during a test run. When the service was deployed to listen for GitHub events, it wouldn’t reject any incoming events sent through the tunnel to the local deployment. After a lot of digging, I traced the issue to the Apache configuration in the mod_wsgi-express server. This server, responsible for serving the Flask-RESTx endpoints, was misbehaving and causing all the trouble.
Another hiccup was that the service was too heavy for my system to run locally in an OpenShift environment with GitHub. My mentor stepped in and suggested a helpful workaround, disable the unnecessary services for our use case and use GitLab instead in plain docker containers, as it’s much easier to spin up and test locally. Reported a few other problems in the deployment process for development regarding Bitwarden for secrets.
With those issues resolved, I went ahead and trimming the parts of the packit-service codebase that weren’t needed for onboarding new packages. This helped me better understand its event model and the use of Celery in task execution.
This week was mostly about reusing the existing packit-service codebase and resolving issues.
What’s Next?
With the hard parts of setup and architecture done, the next steps would be to:
Add new API endpoints and corresponding event types for task handling
Integrate the current setup with COPR for builds.
Begin work on testing and validation workflows
Stay tuned for more updates in the next blog post!
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 7th – 11th July 2025
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
This is the story of how I became a contributor on the Fedora Release Schedule Planner application hosted on Codeberg.
I started my open-source journey when I got my first laptop. It was old and slow, but I needed it for school, so I started looking into how to fix this.
My Introduction to Linux
While looking around for a solution I found Linux, a free operating system that runs on almost anything.
This led me to dip my toes into the Linux world starting with Puppy Linux. This tiny was perfect for my old laptop.
The experience was amazing; I was blown away at how fast and efficient my laptop became. This initial success sparked my interest in learning more about Linux and open source software.
Discovering Open Source Software
Since I was a Windows user before, I had no idea about open source software. I was also broke so all I knew was the endless cycle of looking for cracked software. Using pirated software honestly felt wrong to me.
Playing around on the small Linux distro had me discovering a wealth of free and open source software. Everything from GIMP for image editing, LibreOffice for productivity and Blender for 3D modeling all for freely available. This was liberating; I no longer had to rely on shady sources for software.
Digging further made me realize that I could actually contribute to these free software. The notion that I could not only use but also help improve the software I loved was incredible.
Getting Involved in the Fedora Project
Thanks to how easy Linux makes learning programming, I learned a few languages. This eventually led to me being able to actually make contributions
I also distro hopped a lot and found myself using Fedora as my daily driver. Been using it for a while now and love how stable and polished it is.
Anyway, once I saw that Outreachy was looking for Fedora contributors I decided to apply. There were a lot of skilled contributors to the project I had applied to, but I was determined.
I managed to scrape through and get in as an intern. I am now working on improving Fedora’s release schedule management by transitioning to something more functional and efficient.
The plan is to learn as much as I can from my experienced mentor, Tomas Hrcka. While doing so engaging with all the other open source contributors will provide a great deal of knowledge and networks.
I hope to learn from this experience contributing to Fedora so I can get others involved with open source software.
You visited FrOSCon 2025
