One amazing benefit that modern LLMs come with is using them as a linter, or a pair programmer. You can easily get feedback on your code: just share it with the AI tool and ask a question. If the feedback is solid, your code is improved. If the feedback is poor, you can just disregard it. But overall with very little effort you can gain a lot.

In this article we are going to focus on code review done with AI tools. We are going to explore a few solutions available as of February 2026 and how they compare based on our experience. This is not a thorough analysis nor are we doing any evals.

There are upstream projects that have multiple release streams and, for example, regularly release patch versions for every active minor version. With pull-from-upstream you have been able to follow only the highest stream, but that now changes. By switching Monitoring status of your package from Monitoring to Monitoring all, you enable triggering pull-from-upstream for every released version, not only the highest. This means you can use options such as version_update_mask, upstream_tag_include or upstream_tag_exclude (those require upstream_project_url to be set) to filter a specific release stream you want to follow, or have multiple pull-from-upstream jobs, each matching different releases and targeting different dist-git branches.

We are happy to announce that the ogr library now supports yet another open-source git forge — Forgejo. This brings the total number of supported forges to four. Thank you to all external contributors and especially mynk8 who helped to turn this part of the project into reality!

After building and running AI-powered automation for RHEL package maintenance workflows (available in this repo), our team has learned a lot about what it takes to move from impressive demos to a reliable production system. Here are the key insights that might save you time and frustration on your own AI automation journey.

Are you already familiar with the basic concepts of the specfile library? Then welcome to a collection of some slightly more advanced topics that you could find useful. If you're not that familiar and would like to start with something easier, you can take a look at Introduction to specfile library.

We are reaching the end of the year and it’s a good time to look back at the Packit highlights of this year. And it was a year!

After 105 minor releases we are almost ready to announce our first major release, Packit 1.0.0!

This term has been thrown around a bit in issues here and there relating to the dashboard and people usually get confused, and rightfully so! Lets dive in and see what Project Mycorrhiza is and why we chose this name.

Photo by Malene Thyssen - Own work, CC BY-SA 3.0, Link

Were you annoyed by Packit creating divergent branches in your package's dist-git repository? You'll be happy to know that Packit now supports a new dist_git_branches syntax that enables fast-forwarding commits between branches.

We are happy to announce that support for non-git upstreams in the pull_from_upstream job is here! This enhancement simplifies configuration by removing the need to define upstream_project_url, opening the door for more use cases, while also simplifying the onboarding in general.