what do you exactly mean by "max karma"? I t can mean plenty of things:

• update submitter is not able to set the upper karma threshold to values larger than proposed 3
• the default upper karma threshold should default to proposed 3
• ...

what do you exactly mean by "max karma"? I t can mean plenty of things:

Sorry if this sounded vague, i meant the second point mentioned below:

When a submitting an update, default karma is already 3, i am thinking "do not allow the submitter" to exceed this value, in the interest of ensuring that the updates hit the repos faster.

This is a very small change, but i am trying to find means to ensure security updates hit our repos faster and are available as early as possible.

update submitter is not able to set the upper karma threshold to values larger than proposed 3
the default upper karma threshold should default to proposed 3
...

I don't like the idea. We can display a warning when the maintainer sets the karma higher but we should not forbid it. I trust the packagers they know what they are doing (until they don't, and than I talk to them).

As an example: I add a patch to Python for security fix. I set karma to 2 as I'm fairly confident.

However. I rebase Python from 3.7.1 to 3.7.2 with security updates. Anything can go wrong. I cannot set karma to 3, because Python will almost immediately get several +1 LGTM karmas even before hitting the testing repo. So even with the security aspect in mind, I set the karma to at least 8.

I don't like the idea. We can display a warning when the maintainer sets the karma higher but we should not forbid it. I trust the packagers they know what they are doing (until they don't, and than I talk to them).

Warning works as well, something like
"This is a security update, setting a higher karma (unless required for extensive testing) may delay getting the updated package to users"

As long as submitters are aware (in some way), i am fine.

As an example: I add a patch to Python for security fix. I set karma to 2 as I'm fairly confident.
However. I rebase Python from 3.7.1 to 3.7.2 with security updates. Anything can go wrong. I cannot set karma to 3, because Python will almost immediately get several +1 LGTM karmas even before hitting the testing repo. So even with the security aspect in mind, I set the karma to at least 8.

I don't think such warning would need a FESCo approval. @bowlofeggs ?

I am okay with a warning, I am not okay with forcing anything. For instance, when I push a kernel package, even with a truly critical security fix, I turn off auto karma. The problem is, F29 kernels will usually get 3 karma before they are ever even pushed to updates-testing. I require a certain amount of testing before I am willing to push to the general public. I am sure I am not the only one in those shoes. Also of note, for truly critical (remote priv escalation and the like), a simple request can get it manually pushed live as soon as you are ready.

I am okay with a warning, I am not okay with forcing anything. For instance, when I push a kernel package, even with a truly critical security fix, I turn off auto karma. The problem is, F29 kernels will usually get 3 karma before they are ever even pushed to updates-testing. I require a certain amount of testing before I am willing to push to the general public. I am sure I am not the only one in those shoes. Also of note, for truly critical (remote priv escalation and the like), a simple request can get it manually pushed live as soon as you are ready.

Ack, i think warning should be a good start atleast. Do we need fesco approval for this? or i can just ask bodhi guys to implement this?

I's just open a bodhi RFE and if @bowlofeggs thinks FESCo approval is needed, he can reach back to FESCo.

Closing as invalid, because there is nothing to vote on here ATM.

I agree that FESCo doesn't need to approve a warning in Bodhi. I also don't think we should force packagers to limit testing on updates, even if they are security updates.