From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id yLMJLzYRk1/sNQAA0tVLHw (envelope-from ) for ; Fri, 23 Oct 2020 17:21:58 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id WJ73KjYRk1+uZwAA1q6Kng (envelope-from ) for ; Fri, 23 Oct 2020 17:21:58 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1FAFE94060F for ; Fri, 23 Oct 2020 17:21:57 +0000 (UTC) Received: from localhost ([::1]:48878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kW0lI-0007gE-Si for larch@yhetil.org; Fri, 23 Oct 2020 13:21:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60802) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kW0jp-0005Jq-Hy for guix-devel@gnu.org; Fri, 23 Oct 2020 13:20:25 -0400 Received: from mira.cbaines.net ([212.71.252.8]:53416) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kW0ji-0007qz-Ma for guix-devel@gnu.org; Fri, 23 Oct 2020 13:20:25 -0400 Received: from localhost (92.41.179.191.threembb.co.uk [92.41.179.191]) by mira.cbaines.net (Postfix) with ESMTPSA id 144B227BBEE for ; Fri, 23 Oct 2020 18:20:13 +0100 (BST) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id c1cce200 for ; Fri, 23 Oct 2020 17:20:10 +0000 (UTC) User-agent: mu4e 1.4.13; emacs 27.1 From: Christopher Baines To: guix-devel@gnu.org Subject: Proposed change for the disruptive changes process (staging/core-updates) Date: Fri, 23 Oct 2020 18:20:05 +0100 Message-ID: <877drg3lmi.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=212.71.252.8; envelope-from=mail@cbaines.net; helo=mira.cbaines.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/23 11:31:25 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list 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+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: 0.89 X-TUID: Ro3v+VII94Co --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey, So, the process as I currently understand it, commits that cause lots of derivation outputs to change should be pushed to either the core-updates or staging branches, rather than master. Additionally, these branches should be periodically frozen (no one pushing new changes other than fixes), and then once ci.guix.gnu.org has caught up, the branch and associated changes can be merged to master. From=20both the personal perspective as someone continuously building Guix things to provide substitutes, and from my view on the operation of ci.guix.gnu.org, I think with a small change to the process, could benefit both ci.guix.gnu.org and others building Guix packages. The issue that I'm thinking about with respect to the current process is that ci.guix.gnu.org doesn't just build staging/core-updates when it's frozen, it builds it all the time. This means that on top of the cost of building everything you need to merge the branch, you're potentially spending a lot of time building and storing outputs that no one is ever going to request. Now there is some value in building staging/core-updates all the time, for those who are working on pushing changes/fixing things on those branches, but I think it would be good to allow these things to be separated. I think this issue is clearer for the substitute server I try and operate. I could track and build things off of staging/core-updates, but at the moment it's not worth the cost, because of the amount of redundant building/storing that this would involve. I could also just enable building staging/core-updates when I see that the relevant branch is frozen, but that requires paying attention. A simple process change that I think would help to address this is as follows (I'll use core-updates as the example, but this applies for staging as well): - core-updates is effectively renamed to core-updates-next - When you want to merge core-updates-next in to master, you create core-updates pointing at the same commit as core-updates-next. This begins the freeze. - Once a sufficient amount of time has past for the things on core-updates to have been built, you merge in to master - Shortly after the merge to master, you then delete the core-updates branch This would mean that a build server can track core-updates, and it'll only build things when they're relevant for substitutes. For ci.guix.gnu.org, maybe it could build both branches initially, to replicate the current setup, but I think in the long run, it would be helpful to separate out the behaviour so that ci.guix.gnu.org concentrates on builds for substitutes, and there's another thing for actually testing out potential core-updates changes. Thoughts? Thanks, Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl+TEMVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XetoBAArbiMno0ilCdZAh7Ax9djdDaKRTfjYnM6 NtIb3vppbJ3LU1sAAzPqWM5xc8Y30WS0TCNrKHdhtF7T/ISE1xboXnAufFkg9RgL sx1KKCEaMn1KOX9hL5/kiP9m3ZvxBZRkLSQm4Lb3ajwsB0RZLuYuGFVfXQtEjG19 20uVu5kyMkBoRQ4j/4ljPH2pIyU5bdrrZ5VI8kykoyXqzCO+pWYNtJN8ymOC4JOU gUGJox0sWR9s9jnu2uwX4YGJVnGri/8D0XtEIOAcNQUsLpO925bo8ikLu/tgJP7J j8eAn8QrINsnp05TKnwDMjpnvzrg9WXJ5U2sIoL6oB2GNjYigub2MTHQyZQS61pI +x/QhTNsvvMJRuNlS5wQI8F/hd0pa1fVCZDdsAO/pjcxmC0te8Erz+qCy9bEUK2u 4qsiYDXzxsvnOIoXDs7J4jDyG23n49Av+7lU70Fo5dSGUUHTYfWUX3qzX8STZeSn 9alf9kKwNlCROc4SP6Zhd1bEJSFFBq9/XdHF4LHHqjloKqxaqq5zfemMw4RspQda O5zaq1oyrfXwkJbZ+0jJODjctVyGHpx5W2l7v3jJHn0agkq8v0ycMRWKdupeR7MP 4AUoZoWUM7vHqo/7dQoYkMYqNpe8eaOAQESJyYFAiuXf/ajjc7cUaPlReBqT6r3j JPPYV6XqeD8= =1pjp -----END PGP SIGNATURE----- --=-=-=--