From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0. Date: Wed, 22 Apr 2015 17:23:10 -0400 Message-ID: <871tjb7t8h.fsf@netris.org> References: <1429524721-21449-1-git-send-email-iyzsong@gmail.com> <87618p19aw.fsf@gnu.org> <20150421211500.GA6274@debian> <87pp6x6s6v.fsf@netris.org> <20150422120642.GB4297@debian.math.u-bordeaux1.fr> <87d22w6w9f.fsf@netris.org> <20150422155401.GA6017@debian.math.u-bordeaux1.fr> <87618nzxn2.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]:48190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yl272-0007tk-EG for guix-devel@gnu.org; Wed, 22 Apr 2015 17:23:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yl26y-0005gm-18 for guix-devel@gnu.org; Wed, 22 Apr 2015 17:23:16 -0400 In-Reply-To: <87618nzxn2.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 22 Apr 2015 23:00:33 +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: > Andreas Enge skribis: > >> Now, I would still like some guidelines for what to commit to master and= what >> to core-updates, that we could possibly write down in HACKING (and updat= e when >> the hydra situation changes). Does something like "If you modify PACKAGE= from >> base.scm, or 'guix refresh -l PACKAGE' shows that >=3D N packages are af= fected, >> then commit to core-updates" make sense? If yes, what should be the value >> of N? If not, what would be a better idea? > > I personally use =E2=80=98guix refresh -l=E2=80=99 as the metric to decid= e whether to > create a branch or not. I think it=E2=80=99s a good one though the ideal= one > would be makespan. Another consideration is the current build farm > load. > > The =E2=80=9CCommit Access=E2=80=9D section mentions =E2=80=9Cupgrades th= at trigger a lot of > rebuilds=E2=80=9D, which is quite vague but appeals to =E2=80=9Ccommon se= nse.=E2=80=9D I=E2=80=99m not > sure this can usefully worded as strictly as you suggest. WDYT? I don't think we can decide on a value of N. The decision should be based not on the number of packages, but rather on the expected time that users will be left without binary substitutes of the packages to rebuild, how popular those packages are, how inconvenient it would be for users to rebuild them on their own systems (e.g. icecat is very popular and takes a long time to build), etc. These considerations of the inconvenience to users should be compared with the importance of the update/modification. For example, security updates warrant more inconvenience. How much more depends on the severity of the flaw. I see no good way to formalize this. I think we must rely on our best judgment. What do you think? Mark