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.
Bodhi handles the karma of an update (spanning multiple packages), gathering feedback from the users, with comments. This is distinct from a PR feedback where it's more for the packagers and focuses on a single package. I don't see how konflux in the current or whatever the ultimate proposed state can handle that. Bodhi is explicitly able to do this because it is a distinct service.
I think we should gather these individual "stories" so we can answer the question when it is often suggested that bodhi can go away because XYZ can fill in that role.
Any resources available for that should just be spent maintaining/improving Bodhi (it's an open source project, the ticket tracker is right there, go fix some bugs!)
Very open to that, but the big issue are the big picture issues like the unmaintained cornice dependency [1]. How do we coordinate these issues, or do we even try to tackle?
[1]: https://github.com/fedora-infra/bodhi/issues/6084 -- _______________________________________________ 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
