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: Fri, 24 Apr 2015 18:22:33 -0400 Message-ID: <87fv7pyxna.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ylm07-0005hm-3d for guix-devel@gnu.org; Fri, 24 Apr 2015 18:23:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ylm03-0006lR-VA for guix-devel@gnu.org; Fri, 24 Apr 2015 18:23:11 -0400 Received: from world.peace.net ([50.252.239.5]:48967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ylm03-0006k7-RG for guix-devel@gnu.org; Fri, 24 Apr 2015 18:23:07 -0400 In-Reply-To: <87d22w6w9f.fsf@netris.org> (Mark H. Weaver's message of "Wed, 22 Apr 2015 11:03:08 -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: Andreas Enge Cc: guix-devel@gnu.org Mark H Weaver writes: > Andreas Enge writes: > >> Well, in an ideal world, these two patch sets would be built separately, >> so that any failure could be attributed to one or the other. So I would >> not call two rebuilds "wasted work" in such a context. > > Agreed. If our build farm had enough capacity, this would be ideal. > I should not have said "wasted work". > > Unfortunately, our build farm capacity is quite limited, and its master > machine is currently lacking in RAM and has extraordinarily poor disk > performance. For these reasons, at present, it requires a great deal of > hand-holding to keep it from becoming overloaded to the point of being > unusuable. I do a lot of that work myself, so I'm sensitive to the > issue. > > I'm currently working on building the new hydra.gnu.org which will > hopefully perform much better, although we will still need to work > within our build capacity constraints until we have many more build > slaves. As you can see, even with the trimming of unnecessary jobs that I have already done, Hydra has too much to do and is making very slow progress. I would like to propose that we merge 'wip-glib' into 'core-updates', remove the 'wip-glib' branch and jobset, and focus Hydra on building all of 'core-updates'. What do you think? Mark