On Fri, Mar 7, 2025 at 12:57 PM Brendan Conoboy <blc@xxxxxxxxxx> wrote: > > With all this in mind, the big question is: When and how is it the right time to officially bring up Konflux in the Fedora community context? If it happens too early, it won’t look credible or be useful. If it happens too late, there won’t be an opportunity for interested community members to meaningfully shape its development. So far, Red Hat’s development team has erred on the side of too-early, with presentations in 2024 at Flock and Devconf. Community feedback is valuable and showing up too late to accept it would be a loss. > > Beyond presentations at conferences, the development team has created a Konflux + Fedora SIG, its own community mailing list, and even a matrix chat channel. The astute observer may note that some of the above URLs contain a combination of github.com and fedoraproject.org addresses. Similar to gcc using gnu.org and gnome using gnome.org, Konflux is meant to grow into a proper open source upstream, that many downstreams use, so public presence is not in Fedora alone. > > As it matures, I expect Konflux to be part of the way we improve Fedora CI, to be part of what powers a more intuitive git-native workflow, and an easier onramp for people who don’t currently participate in Fedora to join in with less friction. These dreams may be a little way out, but they are worth pursuing as we bring Forgejo online and realize its potential. So, what are the next steps right now? Let’s talk about it. > I think you are not asking the right question here. This feels like a presupposition that Konflux is the right replacement for our existing infrastructure. But in the time I've heard about Konflux and seen stuff about it, it has bothered me that I haven't heard anyone ask this question: "what do you as Fedora contributors need from our buildsystem that Koji isn't doing now?" Konflux being a skin on Tekton and leveraging OpenShift isn't actually a valuable thing for us as Fedora contributors. The "git-native" workflow is not a real thing. Git is un-opinionated beyond "don't store binaries in it". So I think the question first needs to be asked with the mind that Fedora contributors have experience with our existing build system and want to improve their workflows. If I'm answering that question for myself, I would say that the biggest feature gap that we have from a modern build system like the Open Build Service is that we as packagers have to do dependency resolution for building groups of packages. Nobody *likes* manually sequencing packages for Koji chainbuilds. Nobody likes having to work through reverse dependencies and manually building them when a library has been upgraded. These are serious grunt work things that a computer should do for us. Before I started seriously contributing to openSUSE 10 years ago, I had never conceived it was possible, and now I want that for Fedora contributors. It's a big deal that we don't have it: it means big stacks are hard and time-consuming to upgrade. SIGs like Python, Rust, and Go have to expend a lot of effort to sequence targeted mass builds. Desktops like KDE and GNOME have jalopies of scripts to try to automate build sequencing that are hard to generalize. But in openSUSE, it's just "submit the packages and wait". You don't have to care about the order, it figures it out and bumps the release automatically to make the upgrade path work. This is the kind of thing that would allow Fedora packagers to spend more time on higher-value packaging work and contributing to upstream projects instead. So if we're presupposing a solution, why wouldn't we consider the Open Build Service for Fedora? It has these features and we would massively benefit from them, in addition to OBS doing fully hermetic builds with actual ephemeral VMs rather than chroots or containers (which are *not* good enough for this task). It also has entry points for integrating whatever workflow you like. I ran a private OBS instance for 8 years and was able to integrate workflows for supporting working from Git, leveraging OBS features to have a persistent source cache and adding archive hooks to maintain historical binary builds. The build history database gives you information like "reasons" for why a build was made (dependency change? source change? project owner triggered it? etc.). It offers a very rich experience compared to Konflux and Koji, because it's actually optimized for being a build system, rather than being bolted onto a CI system (Konflux) or being bolted onto an artifact management system (Koji). That's not to say we couldn't have these capabilities with either of those (though I personally think it would be easier to add to Koji than Konflux), but OBS is here and a proper open source project that is set up in a way that anyone can easily deploy. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
