From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: Dealing with mass rebuilds Date: Tue, 20 Oct 2015 23:47:16 +0200 Message-ID: <20151020214716.GA7835@debian> References: <20151020161651.4759.8347@vcs.savannah.gnu.org> <87zizd2ymv.fsf@netris.org> <8737x5e32l.fsf_-_@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoelC-0005TZ-Tn for guix-devel@gnu.org; Tue, 20 Oct 2015 17:47:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoelB-0000L1-V6 for guix-devel@gnu.org; Tue, 20 Oct 2015 17:47:58 -0400 Content-Disposition: inline In-Reply-To: <8737x5e32l.fsf_-_@gnu.org> 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 =?iso-8859-15?Q?Court=E8s?= Cc: guix-devel@gnu.org On Tue, Oct 20, 2015 at 09:45:54PM +0200, Ludovic Courtès wrote: > The Nixpkgs folks have a ‘staging’ branch for changes that cause mass > rebuilds but are well tested, such that they can be merged into ‘master’ > anytime². Perhaps something we should do as well? Would that be different from your suggestion that if the curl update caused a rebuild of too many packages (whatever that would mean, which is a separate discussion) it should not be done on core-updates, but on its own branch, for instance, curl-update? One practical advantage I see in a staging branch, if I understand your suggestion correctly, is that one would not need to modify the set of jobs on hydra to now also build curl-update, and then maybe giflib-update, and then xyz-update, but it would always be called "staging". Now the "well tested" assumption is dubious. I actually do not know whether the curl update will go through. I tried to build one of the packages shown by "guix refresh -l curl" that looked simple (mpd), but it turned out it was not simple at all and needed a lot of rebuilds (including texlive). Admittedly, I could have spent more time searching a direct dependency, probably by using one of your recent graph drawing commands. So in case a problem turns up, would we revert a curl update on the staging branch and do more local work before proposing it again? And if Efraim wished to do a gitlib update after my curl update, what would be the protocol? Would he be expected to wait until the hydra build of the curl update has finished? Or at least until it has finished on x86_64? Otherwise, we would again face the risk of the staging branch becoming an update-the-world branch with unforeseen ramifications. Andreas