On 10/15/26 19:38, Kevin Fenzi wrote:
Several other folks in infra have also expressed desire to re-write it.
It's somewhat of an outlyer in terms of frameworks (it's the only thing
using pyramid), it's the only thing handling it's own email sending,
it's setup very differently than our other flask apps.
This is quite valuable insight, thanks for sharing. From infra
perspective is there a list of changes that would be useful to work on
for the long term maintenance of bodhi to make it easier to cross-maintain?
In tangentially relevant insight from Redhat, they are also trying to find a
solution for a system for more general aggregation of test results, and they
are open to expanding the scope to manage gating, so it may not be too far
off to consider how bodhi could fit into this. The team being formed to work
on this expressed interest in accommodating the Fedora workflow needs, and
the planning is still in early stages that this can be adapted to best fit a
bodhi replacement or individual components.
I agree with Adam here. I don't think we want to add into a 'oh, and
fedora too' application here.
For sure I do not imply that such a solution would be compatible. We are
inevitably going to be asked this same question again, not only for
bodhi, but also koji, and who knows what else. Being able to point back
at a document of here is *all* that would need to be done would be
helpful for both parties to consider. I really appreciate how the
bugzilla replacement is being handled (I will not comment on how that is
going and the meeting, just the initiatives of the people involved) in
both the gathering all of the important workflows that need to be
considered and seeing from the replacement's perspective how these can
or cannot be addressed. I would very much like to see the equivalent of
this applied to the other replacement proposals as well (but in a more
relaxed timeline where everyone has sufficient time to digest these).
First step
Before anything, where should the tracker for this thing be. As a releng or
fesco ticket? Hopefully not as an email/discussion thread?
Tracking what? The long term idea of re-writing it?
Yes, basically. If I were, I would split it into 2 kind of tickets:
- What are the issues we should work on for the bodhi maintenance, and
in which direction. There are thoughts scattered throughout the github
fedora-infra/bodhi, so maybe just coordinating there would be enough
- Gather what bodhi actually does (and how?) so we have a clearer
picture. It does seem that there are components that it should not be
handling by itself like that emails as it was mentioned
I personally dislike tickets for discussing plans. They lack lots of
things actual discussion forums have and tend to just sit around or
driving into the weeds in details.
Open to suggestions. Just continuing the bikeshedding in this thread?
There is a lot of context already shared here, so probably not a bad
option I guess.
I don't know that it would make sense in either fesco or releng...
if you must have a ticket, how about a bodhi one? (which I think there
already is right?).
kevin
--
_______________________________________________
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
