On Mon, Jul 31, 2017 at 5:34 PM, Randy Barlow
<bowlofeggs(a)fedoraproject.org> wrote:
To necromance this old thread, I wanted to give a heads up that
we're about to get a cool feature in Bodhi in response to this thread:
https://github.com/fedora-infra/bodhi/pull/1678
With that pull request, there will be a new request state called "batched".
When non-priority[0] updates reach the karma threshold, they will go into request:batched
instead of request:stable (they will remain status:testing). Once a week, a cron script
will look for all updates in the batched state and will switch them all the
request:stable. Then they will continue on as they do today. This should help us to reduce
the daily churn of Fedora updates for end-users to only be updates they truly need. It may
also make the masher be a little faster on 6 days of the week (and slower on one ☺).
There will still be a little more polish work to do after that pull request is merged.
For example, for non-autokarma updates we want to change the "push to stable"
button to be "push to batched".
[0] The code considers two things to determine whether the update is priority or not:
security updates are high prioritity, and urgent updates are considered high priority. All
other updates are considered "normal" and will go through the new batched
workflow.
I have two questions about this:
1. Are you saying that this feature will be *activated* once it's
merged, or just that it will be available should Fedora decide to turn
it on as a policy decision? I'm assuming it's the latter, as I don't
think I've seen a change proposal or anything be formally filed about
this, and I would have expected that for this kind of change, but it's
not entirely clear to me from this email.
2. If we do implement this, could we consider not batching new package
updates in addition to security and "urgent" updates? New package
updates wouldn't get downloaded onto users systems upon running "dnf
upgrade", so the update process would still *feel* batched from an
end-user point of view. But we would simultaneously be able to deliver
new software quickly to users, or at least as quickly as we do today.
(I find that people rarely test new package updates, or at least
rarely test them and give karma, which means that a newpackage request
generally sits the full 7 or 14 days in bodhi-- so I don't think we
should add up to 7 days to that timetable).
I guess if this were done there might need to be a check put in place
to stop someone from flagging their bodhi update as "newpackage" when
it's not, in fact, a new package to bypass the batching, but this
seems like something that should be easy to do.
Thanks,
Ben Rosser