I wrote an email to devel@ recently to note changes in Bodhi's update requirements code intended to make it more closely implement the current updates policy as written. In response, @kkofler noted that the source of some of those requirements seemed murky.
I did some digging, and wrote up an evaluation of what had happened; it seems like significant and possibly unintentional changes to the policy were made as part of cleanups in 2021, in these two commits:
To summarize as briefly as I can:
@zbyszek intended to have the rewritten policy match both the old policy and Bodhi's behaviour, but I and @kkofler don't think it quite does. (We allege no conspiracy here, only error; both the old policy and Bodhi's old behaviour were confusing and unclear). With Bodhi at the time these rewrites were happening, it was always possible to push a non-critpath update stable with only +1 karma. Sometimes this required some fiddling, and it might superficially have appeared that a +2 requirement was applied to non-critpath updates, but it never really was. You could always get one pushed at +1 somehow or other.
Old Bodhi didn't really implement the "no negative karma" requirement for critpath updates properly, either; since that was dropped in the policy, I also dropped that handling entirely in the Bodhi 8.2 rewrite.
I think the format and phrasing of the modern policy is clearly much better than the old one, but the effective changes to the practical requirements which came along with it - the removal of the "no negative karma" requirement for critpath updates, and the effective change of the minimum karma requirement for non-critpath updates to +2 - may not have been intended, and FESCo may want to re-consider them.
Changing the minimum for non-critpath updates to +1 in Bodhi is trivial and can be done in seconds, if desired. Re-implementing the 'no negative karma' requirement for critpath updates (properly, this time) would be a bit more work but not too onerous, I don't think. It would require a new release of Bodhi.
I would like to point out that the current Bodhi implementation is, by accident, not compliant with the FESCo decisions, and as such would kindly ask FESCo to consider a quick injunction to request the requirement to be changed to +1 as long as there is no FESCo vote approving a higher threshold. Unless of course we can directly get a quick final vote that sets the threshold for non-critpath to +1 once and for all (making any such preliminary injunction moot).
I would also like to point out that I think it kinda makes critpath pointless if we now require the same +2 threshold for all updates.
Well, one way of looking at this is that the old policy was kind of quantum, since it effectively delegated the requirement to the behaviour of the tool, and the behaviour of the tool was weird.
If you never used the CLI or thought of setting the autopush threshold to 1, you might well think the tool (and hence the policy) required +2 karma for all updates, because that's what it would look like to you. If you knew about either of those approaches (or any other way of getting Bodhi to push a +1 update, I feel like there were more but can't remember), then you would see it differently.
So, it's a bit messy :/
To be honest, the only thing that makes critpath updates usefully separate from non-critpath updates is that they run OpenQA tests. And Bodhi won't let an update ship unless it passes tests, so even there the "+2" karma is not extremely meaningful other than to make it harder to ship (which is a value in its own right for critical updates, I'll grant).
There's no point in an injunction since we're far past that. All we can do is request that "+1" karma be allowed for non-critpath updates again. And that, I'm in agreement.
Proposal: Lower the karma threshold for non-critpath updates back to +1. FESCo would like the karma evaluation logic to also be restored as soon as reasonably possible.
EDIT: The latter part is unnecessary, as Bodhi does this part already.
And to make it clear, I'm +1 for the proposal.
Does the second half of that proposal mean you mean you want the "no negative karma for critpath" requirement back?
FWIW, my personal opinion is that we're getting along fine without that, but that's just my two cents.
Does the second half of that proposal mean you mean you want the "no negative karma for critpath" requirement back? FWIW, my personal opinion is that we're getting along fine without that, but that's just my two cents.
If we don't have that, does it still work if overall karma dips into the negative? That's the only thing I actually care about.
Does what still work? I don't understand the question. Currently, updates require a karma total of +2 to be eligible to be pushed. That's 2 positive and 0 negative, or 3 positive and 1 negative, etc. etc. etc.
IIUC, the proposal is this: https://pagure.io/fesco/fesco-docs/pull-request/93
+1
That's what I mean. If that works, we should be good.
+1 to @ngompa 's proposal
Also, I want to say that "No negative karma" should absolutely not prevent pushing. That would lead to abuses where people who are annoyed that their pet bug was not fixed in an update could effectively prevent any update from being pushed until it was fixed. That's too much veto power.
Or someone like the infamous "Jia Tan" might just veto all fixes to their backdoor. I agree that negative karma should only block autopushes, not manual pushes.
Just so I understand correctly - the currently-voted-on proposal makes one single change - critpath updates and non-critpath updates are to be treated differently, with the former having an unchanged (from status quo) minimum positive karma threshold of +2, and the latter being updated to have a minimum positive karma threshold of +1 (instead of status quo of +2)?
Yes. It's effectively status quo ante.
thanks - then I'm +1 too
Well, one way of looking at this is that the old policy was kind of quantum, since it effectively delegated the requirement to the behaviour of the tool, and the behaviour of the tool was weird. If you never used the CLI or thought of setting the autopush threshold to 1, you might well think the tool (and hence the policy) required +2 karma for all updates, because that's what it would look like to you. If you knew about either of those approaches (or any other way of getting Bodhi to push a +1 update, I feel like there were more but can't remember), then you would see it differently. you'd probably think it's +3 as that's the default?
you'd probably think it's +3 as that's the default?
+1 on https://pagure.io/fesco/fesco-docs/pull-request/93#request_diff - critpath needs +2 and other updates can get pushed with +1, default is +3 for both
@dcantrell voted +1 online in the FESCo meeting today. So this is: APPROVED (+9, 0, 0)
Metadata Update from @zbyszek: - Issue tagged with: pending announcement
Announced via "info" in the meeting summary.
Metadata Update from @zbyszek: - Issue untagged with: pending announcement - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Note, changing this in Bodhi actually will require code changes - when revamping Bodhi last year I did not separate critpath and non-critpath karma, as they were identical in the policy. So we'll need to do that. It's not a very difficult change, but I need to write it, write the tests, it needs reviewing, releasing and deploying.
https://github.com/fedora-infra/bodhi/pull/5802 allows for separate values in Bodhi.
I have merged the PR from @adamwill and deployed the code in staging. Note that I forgot to change the default min_karma value in Bodhi's config, so the updates still show with a min_karma set to 2 also for non-critpath updates... anyway, if no one spots any other problem, next week I'll prepare a 8.3 version and a PR in ansible to fix the karma settings.
min_karma
BTW, should the +1 min_karma applied globally or only Fedora (rpm/flatpak/container)? As I summarized in this sheet, the +2 min_karma also apply to EPEL.
Globally.
Log in to comment on this ticket.