From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Rebuilds and branches Date: Sun, 12 Oct 2014 17:58:08 +0200 Message-ID: <87iojpz3e7.fsf@gnu.org> References: <87ppdzvle5.fsf@member.fsf.org> <87wq865kto.fsf@gnu.org> <87tx39yjxk.fsf@netris.org> <87zjd1zbpf.fsf_-_@gnu.org> <87iojpibp1.fsf@yeeloong.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdLX5-0000Zn-IV for guix-devel@gnu.org; Sun, 12 Oct 2014 11:58:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdLX1-0008O6-0a for guix-devel@gnu.org; Sun, 12 Oct 2014 11:58:07 -0400 Received: from hera.aquilenet.fr ([2a01:474::1]:55805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdLX0-0008O1-Pr for guix-devel@gnu.org; Sun, 12 Oct 2014 11:58:02 -0400 In-Reply-To: <87iojpibp1.fsf@yeeloong.lan> (Mark H. Weaver's message of "Sun, 12 Oct 2014 10:50:50 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mark H Weaver Cc: guix-devel@gnu.org Mark H Weaver skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Mark H Weaver skribis: >> >>> ludo@gnu.org (Ludovic Court=C3=A8s) writes: >>> >>>> Eric Bavier skribis: >>>> >>>>> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001 >>>>> From: Eric Bavier >>>>> 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 =E2=80=98libjpeg-update=E2=80=99 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 =E2=80=98core-updates=E2=80=99 branc= h. 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=E2=80=99ll 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 =E2=80=98guix refresh -l=E2=80=99 (200 pa= ckages?), 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 =E2=80=98mas= ter=E2=80=99 stable. WDYT? Ludo=E2=80=99.