This should fix #128 :)

Hm. Thinking about it more, this solves the "no update" issue, but not the "the newer mass rebuild build is not showing up" issue ...

Would it be OK to query mdapi if release == rawhide unconditionally, since bodhi is unreliable in most cases?

Would it be OK to query mdapi if release == rawhide unconditionally, since bodhi is unreliable in most cases?

IIRC there was a performance issue in doing this (ie: it was really slower)

Well ... then I'm not really sure how to solve this for the rawhide case. Since you will not know if the data from bodhi is correct at all until you actually look at the repository data.

Still, it's probably faster to only query mdapi in the case of rawhide, instead of first querying bodhi and then querying mdapi in case bodhi does not return data :) So on average it might even be faster?

Still, it's probably faster to only query mdapi in the case of rawhide, instead of first querying bodhi and then querying mdapi in case bodhi does not return data :) So on average it might even be faster?

Worth trying :)

Ok, querying mdapi for rawhide unconditionally and not changing the behaviour for stable branches makes the function about half a second faster in my local testing (about 7.5 s instead of 8 s).

But the longer I look at it, the more I see corner cases that the current implementation just cannot address. I mean, I could rewrite the whole function and optimize it to make as few remote bodhi+mdapi calls as possible while still delivering correct results, but is that worthwhile?

Ok, querying mdapi for rawhide unconditionally and not changing the behaviour for stable branches makes the function about half a second faster in my local testing (about 7.5 s instead of 8 s).

Oh, I was expected worst, cool :)

But the longer I look at it, the more I see corner cases that the current implementation just cannot address. I mean, I could rewrite the whole function and optimize it to make as few remote bodhi+mdapi calls as possible while still delivering correct results, but is that worthwhile?

Up to you :)

I just found out that neither mdapi nor bodhi have the complete information we'd need ... bodhi does not show builds from releng-managed side tags (like for the mass rebuild), and mdapi only shows data for the latest build (always including updates-testing). So neither is able to reliably return the "latest stable" build ...

So I'm coming down on the side of: this PR actually fixes the wrong mdapi usage in the rawhide case. So it fixes at least that specific bug.

I'll try to think about how to solve the other issue ("old state being shown because the newer build didn't go through bodhi") separately, but I'd rather not implement yet another web service that actually provides useful repo information via API ...

So I'm coming down on the side of: this PR actually fixes the wrong mdapi usage in the rawhide case. So it fixes at least that specific bug.

I'll try to think about how to solve the other issue ("old state being shown because the newer build didn't go through bodhi") separately, but I'd rather not implement yet another web service that actually provides useful repo information via API ...

Agreed, so I'll merge this and we'll see if we can improve a bit in the future

Thanks! :)