Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <m...@netris.org> skribis: >> >>> l...@gnu.org (Ludovic Courtès) writes: >>> >>>> Eric Bavier <ericbav...@gmail.com> skribis: >>>> >>>>> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001 >>>>> From: Eric Bavier <bav...@member.fsf.org> >>>>> Date: Fri, 10 Oct 2014 13:07:55 -0500 >>>>> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. >>>>> >>>>> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a. >>>> >>>> OK. >>> >>> This triggered over 450 rebuilds. I wonder if it should have been done >>> in core-updates instead. >> >> Arf, probably yes, in a ‘libjpeg-update’ branch, rather. > > Well, suppose we update two different core packages in close succession, > e.g. make 4.1 and bash 4.3.30. I don't want two independent rebuilds, > one with make 4.1 and bash 4.3.27 and another with make 4.0 and bash > 4.3.30. Each of those would turn out to be useless.
Right. However, this is not a good example, since both Make and Bash are core packages, so they would go in the same ‘core-updates’ branch. I was rather thinking of packages like libjpeg, libpng, GLib, GTK+, Qt, which have many dependencies, but are fairly independent from one another. Maybe in some cases it’ll make sense to update several of them in the same branch, as you note. >> What about having a policy for that? Like, above some threshold of the >> number of rebuilds reported by ‘guix refresh -l’ (200 packages?), set up >> a separate branch and Hydra job set. > > The severity of the bug being fixed may also be a relevant factor in the > decision. Yes, I was thinking of non-security-critical updates. For bug-fix updates that trigger 200+ rebuilds, it may still make sense to have a separate branch and job set, for the sake of keeping ‘master’ stable. WDYT? Ludo’.
