From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2] Date: Wed, 17 May 2017 19:45:17 -0400 Message-ID: <20170517234517.GA27243@jasmine> References: <87k26chy16.fsf@gnu.org> <87y3u5wwsi.fsf_-_@gnu.org> <20170514135041.GA29369@thebird.nl> <871srrruvi.fsf@gnu.org> <20170515072626.GA963@thebird.nl> <87fug6f7dj.fsf@gnu.org> <86inl127it.fsf_-_@gmail.com> <87vap0aj9x.fsf@elephly.net> <868tlvii2l.fsf@gmail.com> <86shk3gyvr.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB8d8-0003x0-Rt for guix-devel@gnu.org; Wed, 17 May 2017 19:45:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dB8d5-0003Oj-Pp for guix-devel@gnu.org; Wed, 17 May 2017 19:45:22 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:37027) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dB8d5-0003Ma-G2 for guix-devel@gnu.org; Wed, 17 May 2017 19:45:19 -0400 Content-Disposition: inline In-Reply-To: <86shk3gyvr.fsf@gmail.com> 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" To: myglc2 Cc: guix-devel On Wed, May 17, 2017 at 01:46:16PM -0400, myglc2 wrote: > ISTM these can be addressed ... > > - behind: save everything hydra builds, or at least the last few > installation images. Can't we just accomplish this by never doing > "guix gc" on hydra? We need more storage! > - new-commit: Here we want hydra to build every commit that lands in the > guix git repo, prioritizing some branches (e.g. master) over others. We need more computational power, especially in non-Intel-compatible architectures (ARM 32 and 64-bit, and MIPS). Also, if we did something like this, we would not want to build from every commit. Perhaps every push. And only for master; branches like core-updates tend to collect untested patches for a while before we start trying to build the branch. There's no point trying to build every package from branches in that state.