On Mon, Jul 31, 2017 at 5:34 PM, Randy Barlow <bowlofeggs@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
