From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Rebuilds and branches Date: Sun, 12 Oct 2014 10:50:50 -0400 Message-ID: <87iojpibp1.fsf@yeeloong.lan> References: <87ppdzvle5.fsf@member.fsf.org> <87wq865kto.fsf@gnu.org> <87tx39yjxk.fsf@netris.org> <87zjd1zbpf.fsf_-_@gnu.org> 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]:45115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdKUf-0004yA-3d for guix-devel@gnu.org; Sun, 12 Oct 2014 10:51:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdKUZ-0006Ym-VR for guix-devel@gnu.org; Sun, 12 Oct 2014 10:51:33 -0400 In-Reply-To: <87zjd1zbpf.fsf_-_@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Sun, 12 Oct 2014 14:58:36 +0200") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org 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. > 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 pac= kages?), 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. > In an ideal world a patch queue manager would automatically take care of > that. I'm not sure the decision can be made fully automatically, but it would certainly be nice to have some tools to make the job easier. Mark