So, to rephrase this (to make sure I understand it):

The current behavior is that Bodhi updates must spend a duration in testing based on the OS/Release (two weeks for EPEL, one week for stable Fedora releases, three days for testing Fedora releases) unless they hit the karma threshold.

The proposal here is to allow Bodhi to submit the update for stable as soon as it hits the required deadline (optionally requesting a longer minimum), right?

Would negative karma disable the autopush (as it does with the karma threshold)?

Can these be set independently? I might want to have it autopush to F28 after one week in testing, but I actually don't want karma to auto-push it. An example might be a Firefox update: they often go to stable before they even hit updates-testing mirrors, but I might want to enforce a minimum of, say, three days in updates-testing to give it a proper shakedown and then push to stable if it's hit the karma threshold.

I think it's a good idea. This will remove what is a useless manual step for many packages. I'm not sure about the date selector: that'd require additional clicking, so my preference would be just to set the number of days.

I have to agree with @sgallagh that making the karma and delay independently selectable might be useful.

On Tue, 2019-01-08 at 15:32 +0000, Stephen Gallagher wrote:

The current behavior is that Bodhi updates must spend a duration in
testing based on the OS/Release (two weeks for EPEL, one week for
stable Fedora releases, three days for testing Fedora releases)
unless they hit the karma threshold.
=20
The proposal here is to allow Bodhi to submit the update for stable
as soon as it hits the required deadline (optionally requesting a
longer minimum), right?

Correct, for updates that are configured to do this new behavior.

Would negative karma disable the autopush (as it does with the karma
threshold)?

Yes, that's the plan.

Can these be set independently? I might want to have it autopush to
F28 after one week in testing, but I actually don't want karma to
auto-push it. An example might be a Firefox update: they often go to
stable before they even hit updates-testing mirrors, but I might want
to enforce a minimum of, say, three days in updates-testing to give
it a proper shakedown and then push to stable if it's hit the karma
threshold.

I hadn't planned to make them be set independently, though I suppose we
could do that if desired. I'd personally probably prefer to just have
one boolean value to keep it simpler, but I'm not opposed to making it
two if others desire that.

On Tue, 2019-01-08 at 16:04 +0000, Zbigniew J=C4=99drzejewski-Szmek wrote:

I think it's a good idea. This will remove what is a useless manual
step for many packages. I'm not sure about the date selector: that'd
require additional clicking, so my preference would be just to set
the number of days.

We could have the date selector pre-select the release requirement by
default so you only have to click if you want to change it. But I also
don't mind it being an integer box where you just type the number of
days (and this could also reasonably default I think).

I have to agree with @sgallagh that making the karma and delay
independently selectable might be useful.

I'm not opposed to the idea.

I'm in favor of this idea. One less manual chore for maintainers and anyone who doesnt like it can just opt out. So, +1 from me.

+1

Also, I'd prefer if autopush based on karma and autopush based on time could be selected individually.

I am +1 to the idea, though I agree on a possibility to disable autokarma and rely completely on time for updates. With kernel, we tend to hit karma before an update even gets pushed to testing, so we have to disable auto karma, but we would probably use a time based push if it were available.

+1

+1 for just time based with -1 karma veto power.

It might also be nice to do autopushes only on one day of the week for all updates that passed the threshold.

I see 5 pluses. No minuses. Older than a week. Hence this is approved. Will put it into the meeting announcement.

Announced.

I see 5 pluses. No minuses. Older than a week. Hence this is approved. Will put it into the meeting announcement.

What is it exactly that we approved? Do we need another discussion about whether to do autopushes only on a certain day of the week?

We explicitly voted against once-per-week batches in #1820. Granted, this is a slightly different case, because now we're talking about a potentially smaller subset of packages, but I'd be -1 for this kind of batching for the same reasons that applied in the more general case.

My understanding is that we approved the following:

The proposal here is to allow Bodhi to submit the update for stable as soon as it hits the required deadline (optionally requesting a longer minimum).

Do we need another discussion about whether to do autopushes only on a certain day of the week?

I'm -1 for that for the same reasons as given by @zbyszek.

Until now, the push to stable would happen in arbitrary time once the packager hits the button.

With this feature, it would happen automatically after a certain time passes.

I don't really see how this changes anything about if the updates should be batched.

The problem with the previous implementation was that it was opt-out and unclear what to do. With the new proposal the maintainer would explicitly tell Bodhi that they do not care that it is pushed to stable ASAP. Since there are users that would like to have updates less often AFAIK it seems to be a good set of updates to test this with.

For me, this ticket is a solution to the following problem: an update needs to spend some time in updates-testing to give testers a chance to report issues, but I'm likely to forget to push it after the time comes. For other packages, it is a solution to the problem of too much karma: the update should spend a few days in updates-testing even if karma is reached.
In both cases, we want the update to go to stable, without undue delay. If we re-introduce batching like you suggest, this adds a potential delay of up to 6 days on top of the specified testing time. If e.g. firefox maintainer specifies that they want to wait for +5 karma and at least two days, in no way it follows that they are OK with the update going out after 8 days.

Edit: also, batching here shares many of the same problems as in the other case: it happens in the wrong place in the pipeline. If users want batching, then they can most effectively implement it on their side. Delaying some packages on the input side makes the batching mandatory for users that don't want this too.

I think that batching and this are mostly orthogonal issues and enabling batching for this will make this feature less useful and less used.

ok, thank you two, i am persuaded to not follow-up on batching anymore.

I filed an RFE upstream: https://github.com/fedora-infra/bodhi/issues/2978

I tried to capture the details that were requested in comments here, such as independent booleans and date selectors. Let me know if I missed anything. Thanks!

Hum, so this pivoted from the initial idea of "do autopush based on time instead of autopush based on karma" to "allow both time-based and karma-based autopush at the maintainer's discretion, possibly with AND and OR possibilities"? That seems like quite a shift. Is there a specific decision on what the new default should be? Default settings are very important, as I think something like 95% of updates keep the default setting.

Hey @adamwill!

I hadn't intended to replace the push based on karma, just to add another automatic push based on time.

As for defaults, I would think the required time in testing that we already have defined would be reasonable (7 days for most updates, 14 for critpath and EPEL).

Did everyone in FESCo have the same understanding, or do we need to reopen for clarification?

I've +1 the ability to set autopush based on time. I have never considered this to replace autopush based on karma.

As for defaults, I considered this would be opt-in for now, and after some "reasonable time period", we have another discussion about defaults that make this opt-out.

@bowlofeggs "I hadn't intended to replace the push based on karma, just to add another automatic push based on time."

ah OK, I must've misunderstood that aspect of the original proposal/discussion, then. I thought part of the goal here was to avoid packages getting autopushed five minutes after submission due to +ve karma from those folks who seem to +1 absolutely every update...

@adamwill I believe the desire from my management chain was to remove the human step of clicking "push to stable" after a week.

@churchyard I had planned to make it the default, since we currently also default to the automatic push based on karma. If we have the two bools have opposite defaults, that might be odd from a consistency perspective. Defaulting to it being enabled would be more in line with the overall goal I mentioned to Adam above. However, I don't think we voted on what the default should be. Do you want me to file a ticket to vote on a default?

I don't think FESCo needs to approve bodhi defaults if they don't contradict any policy. Which here they don't, so use your best judgement ;)