Re: Security updates and batched pushes

Randy Barlow wrote: > It would help people with more minimal package sets more often. On days > with just a handful of updates, it's possible that some users don't use > any of them and thus don't have to get notified. Even if they don't get notified, they still have to download the whole

Re: Security updates and batched pushes

On 01/18/2018 10:13 AM, Kevin Kofler wrote: > But whom does this help? There are still updates going out daily, the > repodata download cost is still there, the notifications too if you aren't > doing client-side batching (and if you are, you don't need server-side > batching to begin with).

Re: Security updates and batched pushes

> On 18. Jan 2018, at 16:13, Kevin Kofler wrote: > > Am I the only one who bothers reading update notes? Nope. BK ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Security updates and batched pushes

Randy Barlow wrote: > The original intent as I understood it from the thread long ago[0] was > to reduce the number of updates that go out on non-Tuesdays, and make > most updates happen on Tuesdays. The data that Kevin cited seems to be > accomplishing that purpose. But whom does this help?

Re: Security updates and batched pushes

I wrote: > This week, there have been almost daily nonempty update pushes (listing > only the SRPMs here, and only the updates that affected me): > * Jan 10 (previous batch) > * Jan 11 (not batched, gtk3 and microcode-ctl) > * Jan 12 (not batched, kernel, dhcp, dnfdragora, hplip, webkitgtk4) > *

Re: Security updates and batched pushes

On 01/17/2018 08:47 AM, mcatanz...@gnome.org wrote: > Clearly what we have now is, in practice, not working as intended. The original intent as I understood it from the thread long ago[0] was to reduce the number of updates that go out on non-Tuesdays, and make most updates happen on Tuesdays.

Re: Security updates and batched pushes

Thanks, Kevin. Knowing when the updates are actually going out adds important context to this discussion. On Wed, Jan 17, 2018 at 7:30 AM, Kevin Kofler wrote: I don't see how this is helpful. Kevin has a point here. Clearly what we have now is, in practice, not

Re: Security updates and batched pushes

Kevin Fenzi wrote: > On 01/09/2018 12:57 PM, Kevin Kofler wrote: >> Kevin Fenzi wrote: >>> If we update a repo for some minor enhancements it means everyone in the >>> world has to pay for that. If we just push all those out every tuesday >>> and don't update those unless there's something urgent

Re: Security updates and batched pushes

On Wed, 2018-01-10 at 08:06 -0800, Kevin Fenzi wrote: > On 01/09/2018 02:09 PM, Tim Landscheidt wrote: > > BTW, are there technical reasons why the metadata is updated > > en bloc and not incrementally like for example delta RPMs, > > or is it just that nobody bothered to implement something > >

Re: Security updates and batched pushes

On Wed, Jan 10, 2018 at 2:23 PM, Andrew Lutomirski wrote: >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi wrote: >> >>> On 01/08/2018 10:53 AM, Kevin Kofler wrote: >>> Kevin Fenzi wrote: Well, if this firefox update was urgent, shouldn't it have been marked

Re: Security updates and batched pushes

One followup that should help people understand things: When someone pushes an update to a package that isn't in Atomic Host (or Workstation), *and* one is using rpm-ostree in "pure ostree" mode (i.e. you never ran `rpm-ostree install`), then checking for updates just uses libostree, which like

Re: Security updates and batched pushes

On Wed, Jan 10, 2018, at 2:38 PM, Stephen John Smoogen wrote: > > This sounds a lot like the Atomic project and how it does things... Atomic could mean either (rpm)-ostree or Docker/OCI. In the Docker/OCI world search isn't standardized yet AIUI but there's progress on that upstream. I am

Re: Security updates and batched pushes

On 01/09/2018 02:09 PM, Tim Landscheidt wrote: BTW, are there technical reasons why the metadata is updated en bloc and not incrementally like for example delta RPMs, or is it just that nobody bothered to implement something like that yet for metadata? This has been discussed for a very long

Re: Security updates and batched pushes

On Wed, Jan 10, 2018 at 12:01 PM, Stephen John Smoogen wrote: > > On 10 January 2018 at 14:46, Andrew Lutomirski wrote: > > > > > > On Wed, Jan 10, 2018 at 11:38 AM, Stephen John Smoogen > > wrote: > >> > >> On 10 January 2018 at 14:23, Andrew

Re: Security updates and batched pushes

On 10 January 2018 at 14:46, Andrew Lutomirski wrote: > > > On Wed, Jan 10, 2018 at 11:38 AM, Stephen John Smoogen > wrote: >> >> On 10 January 2018 at 14:23, Andrew Lutomirski wrote: >> >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi

Re: Security updates and batched pushes

On Wed, Jan 10, 2018 at 11:38 AM, Stephen John Smoogen wrote: > On 10 January 2018 at 14:23, Andrew Lutomirski wrote: > >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi wrote: > >> > >>> On 01/08/2018 10:53 AM, Kevin Kofler wrote: > >>> Kevin Fenzi

Re: Security updates and batched pushes

On 10 January 2018 at 14:23, Andrew Lutomirski wrote: >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi wrote: >> >>> On 01/08/2018 10:53 AM, Kevin Kofler wrote: >>> Kevin Fenzi wrote: Well, if this firefox update was urgent, shouldn't it have been marked

Re: Security updates and batched pushes

> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi wrote: > >> On 01/08/2018 10:53 AM, Kevin Kofler wrote: >> Kevin Fenzi wrote: >>> Well, if this firefox update was urgent, shouldn't it have been marked >>> urgent? >> >> Urgency is always in the eye of the beholder. I as a user consider

Re: Security updates and batched pushes

On 01/10/2018 04:01 AM, Tomasz Torcz wrote: > > So, if there ARE updates to be pushed (marked urgent?) and we update > metadata > ANYWAY, this is a good point to flush everything from batched in this push. We could yeah. We could also only ever push when there are urgent updates... kevin

Re: Security updates and batched pushes

On 01/09/2018 12:57 PM, Kevin Kofler wrote: > Kevin Fenzi wrote: >> You also don't want updates-testing to even exist right? > > That is not true. I want to leave the decision whether and for how long an > update needs to be tested to the package maintainer instead of enforcing > minimum

Re: Security updates and batched pushes

On 01/09/2018 02:09 PM, Tim Landscheidt wrote: > Kevin Fenzi wrote: > >> […] > > I really don't understand why we do this "batched" thing to begin with. > To reduce the constant flow of updates that are very minor or affect very few mixed in with the major

Re: Security updates and batched pushes

On 01/08/2018 01:36 AM, Kevin Fenzi wrote: On 01/07/2018 01:38 PM, Christian Dersch wrote: Hi all, within the whole Meltdown and Spectre story I realized that Koji pushes even security updates to batched only, not directly to stable. In The critera for bypassing batched is if the update

Re: Security updates and batched pushes

January 9, 2018 9:59 PM, "Kevin Kofler" wrote: > Kevin Fenzi wrote: > >> To save all the Fedora users in the world from having to update metadata >> for minor changes. Since there's a hourly dnf makecache every user in >> the world pulls down new metadata ever time we

Re: Security updates and batched pushes

Kevin Fenzi wrote: > […] I really don't understand why we do this "batched" thing to begin with. >>> To reduce the constant flow of updates that are very minor or affect >>> very few mixed in with the major updates that affect lots of people and >>> are urgent. >> But

Re: Security updates and batched pushes

Matthew Miller wrote: > Also, I think everyone in this discussion on _this_ list who would like > updates faster should probably be using updates-testing. Or at least > _looking_ at updates-testing. You can always pull individual updates > from there on a per-package basis, and doing this helps

Re: Security updates and batched pushes

Kevin Fenzi wrote: > You also don't want updates-testing to even exist right? That is not true. I want to leave the decision whether and for how long an update needs to be tested to the package maintainer instead of enforcing minimum testing requirements in the software, because the software

Re: Security updates and batched pushes

On 01/08/2018 10:53 AM, Kevin Kofler wrote: > Kevin Fenzi wrote: >> Well, if this firefox update was urgent, shouldn't it have been marked >> urgent? > > Urgency is always in the eye of the beholder. I as a user consider all > security updates "urgent", and in addition, I want ALL updates as

Re: Security updates and batched pushes

On Tue, Jan 09, 2018 at 02:17:43AM +, Peter Robinson wrote: > I thought for some reason that all updates marked as security were > automatically urgent, maybe I'm misremembering, but if not it might be > good to do that as a RFE that way all security updates go out non > batched. There was

Re: Security updates and batched pushes

On Mon, Jan 8, 2018 at 8:17 PM, Peter Robinson wrote: I thought for some reason that all updates marked as security were automatically urgent, maybe I'm misremembering, but if not it might be good to do that as a RFE that way all security updates go out non batched.

Re: Security updates and batched pushes

On Mon, Jan 8, 2018 at 5:39 PM, Kevin Fenzi wrote: > On 01/07/2018 08:01 PM, Kevin Kofler wrote: >> Kevin Fenzi wrote: >>> The critera for bypassing batched is if the update is marked "urgent". >> >> The problem is, this appears to be insufficient. > Well, if this firefox update

Re: Security updates and batched pushes

On Mon, 08 Jan 2018 19:53:01 +0100 Kevin Kofler wrote: > Batching really needs to be left to the client side! Right. I did wonder what was going on with the updates... dnf-cron, gnome-software etc could all *default* to weekly. But if I'm doing a dnf update, I want

Re: Security updates and batched pushes

Kevin Fenzi wrote: > Well, if this firefox update was urgent, shouldn't it have been marked > urgent? Urgency is always in the eye of the beholder. I as a user consider all security updates "urgent", and in addition, I want ALL updates as soon as they passed testing no matter whether they

Re: Security updates and batched pushes

On 01/07/2018 08:01 PM, Kevin Kofler wrote: > Kevin Fenzi wrote: >> The critera for bypassing batched is if the update is marked "urgent". > > The problem is, this appears to be insufficient. Well, if this firefox update was urgent, shouldn't it have been marked urgent? > I really don't

Re: Security updates and batched pushes

>> within the whole Meltdown and Spectre story I realized that Koji pushes >> even security updates to batched only, not directly to stable. In > > The critera for bypassing batched is if the update is marked "urgent". Or once you push it stable and it's queued for bat

Re: Security updates and batched pushes

Kevin Fenzi wrote: > The critera for bypassing batched is if the update is marked "urgent". The problem is, this appears to be insufficient. I really don't understand why we do this "batched" thing to begin with. Users who want to batch updates have always been able to do it, GNOME Software

Re: Security updates and batched pushes

On 01/07/2018 01:38 PM, Christian Dersch wrote: > Hi all, > > within the whole Meltdown and Spectre story I realized that Koji pushes > even security updates to batched only, not directly to stable. In The critera for bypassing batched is if the update is marked "urgent"

Security updates and batched pushes

Hi all, within the whole Meltdown and Spectre story I realized that Koji pushes even security updates to batched only, not directly to stable. In concrete case we have the firefox update [1], which already received 10 positive karma and many users complaining that it takes so long to get it out