Proposal: default autokarma +5 for critical path updates

[AdamWill]

In an active discussion about recent problematic updates, pg-tips pointed out a recent update which followed a pattern I've seen before:

• Update reached testing 2025-11-22 02:24
• besser82 gave it positive karma 2025-11-22 10:17:14
• phantomx gave it positive karma 2025-11-22 14:21:03
• markec gave it positive karma 2025-11-22 19:43:29
• update was auto-submitted for stable 2025-11-22 19:43:33 - 17 hours and 19 minutes after it reached testing
• nucleo gave it negative karma 2025-11-23 11:38:14
• anifyuliansyah gave it negative karma 2025-11-23 14:58:00
• multiple other reporters gave negative karma over the next day or so

There have been multiple other cases like this in the past. The fact that there are folks who are very fast to give positive karma to new updates means the +3 autopush threshold is pretty 'risky' for high-stakes updates.

As a simple proposal: how about we make the default karma autopush value 5, instead of 3, for critical path updates?

This would be a bit unfortunate for minor desktops, as they're still 'critical path', but they can still set it lower manually. And I think we've had enough cases like this by now to justify shifting the balance a little further in the conservative direction.

This is pretty trivial to implement, too.

[mcatanzaro]

As a simple proposal: how about we make the default karma autopush value 5, instead of 3, for critical path updates?

Or keep things simple and change it for all updates, because why not?

[AdamWill]

well, most updates just don't get that much feedback so they're never going to get close to +5. they rarely get to +3 so you could argue the difference is academic, I guess.

From my memory of the code it's not much more complex to do it only for critpath (either in implementation or testing). but either is probably fine, really. The maintainer always has the option to change the value if they don't like it.

[kparal]

Autopush by time is also enabled by default, so if non-critpath updates don't get to +3 or +5, they get pushed in a week anyway. I think that's fine. So if it is simpler to implement +5 for everything, there's no harm. If it's the same amount of work, having different values also sounds OK.

[mattiaverga]

I think the discussion, together with #6020 , would better suited to happen under FeSCO.
To summarize (since I'm always confused by this) currently we have

• a floor for manually pushing to stable at minimum time in testing OR a minimum positive karma (values can be set separately for critpath)
• "virtual" settings for autopush on time OR karma: the server just validate values passed by clients to be equal or greater of the floor (for bodhi cli and webUI those are +3/-3 for autokarma and 7 days for autotime).

In current prod:

# The net karma required to submit updates to a pending release.
min_karma = 1
critpath.min_karma = 2

# Allow critpath to submit for stable after 2 weeks with no negative karma
critpath.mandatory_days_in_testing = 14

# The minimum amount of time an update must spend in testing before
# it can reach the stable repository
fedora.mandatory_days_in_testing = 7
fedora_container.mandatory_days_in_testing = 7
fedora_epel.mandatory_days_in_testing = 7
fedora_epel_modular.mandatory_days_in_testing = 7
fedora_epel_next.mandatory_days_in_testing = 7
fedora_flatpak.mandatory_days_in_testing = 7
fedora_modular.mandatory_days_in_testing = 7

Adding new settings just to change the autopush values doesn't have much value in my opinion, since users will still be able to lower the bar to the floor values.
I think we should enforce the mandatory_days_in_testing value, so that min_karma could not bypass it. Perhaps it can be lowered to 2 days / 3 days for critpath, but it must be reached even if min_karma is reached before. That would also be consistent with the phrase "The minimum amount of time an update must spend in testing before it can reach the stable repository".

[AdamWill]

Adding new settings just to change the autopush values doesn't have much value in my opinion, since users will still be able to lower the bar to the floor values.

We don't need to add a new setting. All we do is change the default value from 3 to 5. The default is written straight into Bodhi, somewhere - the webui frontend code or something (I don't remember off the top of my head, but it's definitely there). Yes, update owners can change it, but the vast majority don't, even when I go out and ask them to. So changing the default has a lot of impact/value.

I think we should enforce the mandatory_days_in_testing value, so that min_karma could not bypass it. Perhaps it can be lowered to 2 days / 3 days for critpath, but it must be reached even if min_karma is reached before. That would also be consistent with the phrase "The minimum amount of time an update must spend in testing before it can reach the stable repository".

That's more or less my proposal in #6020 , basically, but I don't think we can do it by lowering mandatory_days_in_testing, because that's the manual push requirement. If we lower that to 2/3 days, people can push updates with no karma stable manually after 2/3 days, which we don't want.

I think the discussion, together with #6020 , would better suited to happen under FeSCO.

The default autopush value is listed in the policy, yeah, so we should at least run it by them. I can open a ticket there.

[mattiaverga]

Adding new settings just to change the autopush values doesn't have much value in my opinion, since users will still be able to lower the bar to the floor values.

We don't need to add a new setting. All we do is change the default value from 3 to 5. The default is written straight into Bodhi, somewhere - the webui frontend code or something (I don't remember off the top of my head, but it's definitely there). Yes, update owners can change it, but the vast majority don't, even when I go out and ask them to. So changing the default has a lot of impact/value.

Ah, yes, we can change the hardcoded values in the form html template and in bodhi-cli code... however, other tools used by packagers to submit their update (fedpkg?) would need to be changed as well.

I think we should enforce the mandatory_days_in_testing value, so that min_karma could not bypass it. Perhaps it can be lowered to 2 days / 3 days for critpath, but it must be reached even if min_karma is reached before. That would also be consistent with the phrase "The minimum amount of time an update must spend in testing before it can reach the stable repository".

That's more or less my proposal in #6020 , basically, but I don't think we can do it by lowering mandatory_days_in_testing, because that's the manual push requirement. If we lower that to 2/3 days, people can push updates with no karma stable manually after 2/3 days, which we don't want.

If I were in Fesco, my opinion would be that we either have to accept packager decisions or enforce a testing period. If we lower mandatory_days_in_testing to 3 days, we should accept that a packager that is manually pushing the update to stable even without users feedback knows what is doing. The other way, if we want to enforce a testing period, we should accept that a package lays in testing for X days even with 100 positive karma.
I don't see the need of a mandatory_days_in_testing_for_real value... ;-)

[AdamWill]

Ah, yes, we can change the hardcoded values in the form html template and in bodhi-cli code... however, other tools used by packagers to submit their update (fedpkg?) would need to be changed as well.

Ah, yeah, fedpkg has the default hardcoded too, good catch.

If I were in Fesco, my opinion would be that we either have to accept packager decisions or enforce a testing period.

I think it's more complex than that, which is why we have the current policy. But we should probably discuss that in #6020 anyway.

[AdamWill]

Another case this would have avoided: Thunderbird update which crashes on startup depending on your screen resolution.

[mattiaverga]

So, if we want to just change the default value (for all updates), it is enough to change:

bodhi/bodhi-server/bodhi/server/templates/new_update.html

Line 326 in f1de048

value="3"

and

bodhi/bodhi-client/bodhi/client/cli.py

Line 141 in f1de048

click.option('--stable-karma', type=click.INT, help='Stable karma threshold'),

This will not prevent the user or other tools/scripts to manually set it to a lower value (down to the min_karma for the release). I don't think this needs to be discussed by FESCo, unless we want that value to be mandatory.