On Thu, Oct 15, 2026, at 12:05, Cristian Le via devel wrote: > On 10/15/26 17:33, Adam Williamson wrote: > >> I think it only makes any sense to replace Bodhi as part of a larger >> workflow redesign which is properly resourced and which *considers >> Fedora's requirements from the start*, not as a kind of late add-on, as >> unfortunately tends to be the case with RH efforts lately. > > Indeed I agree there. But I think we should give a feedback on why an > approach that is currently being considered would not fit us. I am > providing my feedback on that design, for example (and Miro Vadkerti is > welcome to expand) one of the design that I see as being incompatible is > that all of the features that we need would be part of a bigger > application (testing-farm). But I see that as not being too useful for > us because of the contribution process being in a different forge, > having less flexibility to work on the specific features we need > independent of the bigger service, less control in prototyping smaller > changes in the stg infra like we do now. And I do suggest that having > something more modular with smaller services could help us with those > issues. And we do get a benefit from not taking on all parts of bodhi, > e.g. the gating part that is common in both environments can be shared. > > So I do hope we can gather these kind of feedback and try to break the > curse of the RH efforts not being compatible because Fedora needs are > just an afterthought. > >> If we actually do re-design the whole Fedora build process around >> Konflux, for e.g., it would make sense to look at whether it's feasible >> to engineer Bodhi out at that point (and whether it actually saves time >> and effort over just integrating Bodhi into the new process). I don't >> see any value in trying to replace it within the current process >> though. > > Actually this one of the things I think we should gather more info on. > What is the big picture role of bodhi, and would any of the things be > able to fill its shoes. Let me be more concrete with an example since > the topic is brought up. >
Do we have a FULL image of the current build system with all of its many resource requirements, feedback loops and side tools? The reason is that many of the tools which go into getting packages from `fedpkg` -> `mirrors.fedoraproject.org, quay.io, etc` tie into each other in ways not readily documented in the past. There have been many times where taking X out of the tree ended up breaking 2 or 3 other things which no one knew were using X "because it did this one thing easily." One of the reasons that I think many of the Red Hat 'replacement' or 'addition' tools have blown up so badly is because people would think "oh bodhi/packagedb/etc does this one thing" and it ends up being 40 other things that no one realized or had designed for. -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
