From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2GuhONdYH2B0fQAA0tVLHw (envelope-from ) for ; Sun, 07 Feb 2021 03:04:55 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 2J9dNNdYH2AVSQAAB5/wlQ (envelope-from ) for ; Sun, 07 Feb 2021 03:04:55 +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 398D19404C7 for ; Sun, 7 Feb 2021 03:04:55 +0000 (UTC) Received: from localhost ([::1]:56198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8aNZ-0007Pn-Vm for larch@yhetil.org; Sat, 06 Feb 2021 22:04:54 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60258) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8aNE-0007PV-Le for guix-devel@gnu.org; Sat, 06 Feb 2021 22:04:32 -0500 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]:34317) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l8aNB-0000E2-MM for guix-devel@gnu.org; Sat, 06 Feb 2021 22:04:32 -0500 Received: by mail-pg1-x535.google.com with SMTP id o7so8038930pgl.1 for ; Sat, 06 Feb 2021 19:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version; bh=IKLgbAUNY/hM9Xt0ieZmcUYN+NBIB0mb9Hl5Mj0Ho58=; b=hST6CPRh5snoR5Dtz4ak9rSOic9v62Melfr+1HuBAPQie/X0hdJMDQHQQ/uaoVchAG 3KeDZqJ6YAVJBEPgxHSVBBYOfacgVCFUXDG6FgpDB16EPREJAZvqAZobT5HuiLkLQtrF gmylLh/HJvy6FgN/nNkuDLQKhn/VP/SuxUOtlxjAu/uj+9i+L5u/gLxAmnt8exI2YiSF B1Mp0Aywp4G46/2wzS853F89YVg8JqI7HH0juB6893W96s5jRP0dXNVgO3RLvn8bSPKl yuIlbLroaFjijPQpL1fF/1W7c8yAzr+q/S/D9wC17AmweMW87HqMjuKM87N5afo7mrFX u2ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:message-id :user-agent:mime-version; bh=IKLgbAUNY/hM9Xt0ieZmcUYN+NBIB0mb9Hl5Mj0Ho58=; b=f+4GsQBOB+3neK7xD3Y8KjU/VLPL6hOvA5j1GVc4zVWaXjOAWMAAjVsyGcxFua7hhM LVVh/T3ycR9prAUExKSMC6PK7jM7UsUDqJQmMyxO98ydTuhqlKq9qjzjNtRvRNFyYiSk d9GAgkI0NxBHcWPvjcLId/Aocmct9JvdyhQ7JSwT/5rFTYt/UgGIe7Wncdr4ch/DZf81 SNtbDkoEB/fJRONQfYyJYCslUxnqNonq2RS9L76kBtBNBl/PIIPxqwn2H4RnbyKMbOsN VmyYNV/o0QkID0xZKFwC/ZSkx3Kl1fuxTXot6/6vd/NCRmMFz4AhYHFykUiSfoFmaSE9 hx/w== X-Gm-Message-State: AOAM532gQ1+EsFGlFBWt1fA2v3vxDd4sOFawMjcK786kT1+C/+Tnk7mb gDnVxR3ck/7qvyFKxq2k8OBtscJtTKe3Ww== X-Google-Smtp-Source: ABdhPJzlhF6emx2LJIjyu2SoSz+EN1MMm61zg61v70lofPYLXc7Scn+joPqnJ5iQuwIhs7xS6MT8Gw== X-Received: by 2002:a63:fa55:: with SMTP id g21mr11210789pgk.294.1612667067300; Sat, 06 Feb 2021 19:04:27 -0800 (PST) Received: from garuda-lan (c-24-18-44-142.hsd1.wa.comcast.net. [24.18.44.142]) by smtp.gmail.com with ESMTPSA id x81sm14241167pfc.46.2021.02.06.19.04.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Feb 2021 19:04:26 -0800 (PST) From: Chris Marusich To: Christopher Baines Subject: Re: Branch management, wip-ppc64le, and POWER9 References: <87k0romcrz.fsf@gmail.com> <87k0romcrz.fsf@gmail.com> <877dnoyxy4.fsf@cbaines.net> <877dnoyxy4.fsf@cbaines.net> Date: Sat, 06 Feb 2021 19:04:22 -0800 Message-ID: <875z34tw7d.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=2607:f8b0:4864:20::535; envelope-from=cmmarusich@gmail.com; helo=mail-pg1-x535.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -0.86 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20161025 header.b=hST6CPRh; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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-Migadu-Queue-Id: 398D19404C7 X-Spam-Score: -0.86 X-Migadu-Scanner: scn1.migadu.com X-TUID: kx+xIDOKI5TK --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Christopher Baines writes: > I think rebasing introduces issues with commit signatures, since you'd > then be signing others commits. If multiple people are committing to the > branch, I'd treat it like staging/core-updates, and merge rather than > rebasing. Leo Famulari writes: > The signatures will be lost, but for "wip-" branches the expectation has > always been that history may be rewritten. For me, rebasing is a more > comfortable workflow for this kind of exploratory branch. I recommend > against using merges here. The original signatures will be lost, yes. Depending on how you've configured Git, your own signature may or may not be applied to the newly recreated commits. I just tested this in a throwaway repository, and when I rebase commits, I re-sign my commits. However, that is probably because I've set commit.gpgSign to true in my git config. Either way, you're right that it's important to watch out for. Regarding rebasing vs. merging, both can work. I think it depends on who is making the changes. For now, I would prefer to avoid rebasing on wip-ppc64le. If somebody wants to commit, please feel free, but please make sure the commits are of the same quality that you would normally expect for changes going to master, core-updates, or staging, since eventually we will be merging it into those branches. If we need to rebase wip-ppc64le, that's fine, but let's talk about it first so nobody (especially me!) is caught off-guard. For other wip branches, I think whoever is working on them should agree on how to coordinate. I'm just focusing on wip-ppc64le right now, since I want POWER9 support. Christopher Baines writes: > core-updates is pretty broken at the moment (building the channel > derivation fails), so I wouldn't recommend that. This is good to know! I'll try to find a stable point from which to merge, when the time comes (which might be soon!). > Merging master as soon as conflicts arise sounds good, I think it's > easier to handle the conflicts in smaller batches, so more frequent > merges are useful. I agree. Frequent merges (or rebases) are important for avoiding conflicts. Merges from stable points, if possible, are better than merges from random commits in a branch, though. > Once both branches are in a good state, maybe then will be the time to > merge core-updates in to wip-ppc64le to test that combination of > changes, and then if that goes well, merge wip-ppc64le in to > core-updates and stop using the wip-ppc64le branch. On IRC, dftxbs3e also mentioned that it would be unwise to merge from core-updates at this time for other reasons, beyond simply "guix pull" possibly being broken. So we'll be holding off on merging core-updates into wip-ppc64le just yet. See here for details (search for "merge"): https://logs.guix.gnu.org/guix/2021-02-06.log When wip-ppc64le is in better shape, we can decide what to do. In the meantime, dftxbs3e and I agree that it would be best to cherry-pick essential fixes that are already on core-updates (e.g., I cherry-picked a48a3f0640d76cb5e5945557c9aae6dabce39d93 onto wip-ppc64le), rather than merging core-updates prematurely. >> - For Efraim specifically, there is some overlap between the work >> required on wip-ppc64le and the work required on wip-ppc. I have >> already cherry-picked one of your commits >> (2da8fcfdee7cfde8110a68806f3c4d497f217fe5) onto wip-ppc64le (as commit >> 52f0b3db6ef3d3c5067c704c2190f72d2994a999), since it was needed. How >> would you like to coordinate this work? >> >> - Are there any other tips/advice/rules? > > I'd really like to develop the Guix Data Service instance here [1] and > associated Guix Build Coordinator instance in to something that can be > used to work with non-master branches. > > 1: https://data.guix-patches.cbaines.net/ > > wip-ppc64le is already being processed [2], but ppc64le derivations > aren't being computed. I think adding a change like [3] to the branch > would make sense, and prompt the Guix Data Service to compute those > derivations. > > 2: https://data.guix-patches.cbaines.net/repository/2/branch/wip-ppc64le > 3: https://git.guix-patches.cbaines.net/guix-patches/commit/?h=3Dwip-lle-= bout-le1&id=3D53dcca860787ae6cf3949d9c03c0108c47d47c9e > > Once there are computed derivations, then the connected Guix Build > Coordinator instance can start building them. This isn't meant for > providing substitutes to users, but instead for quality assurance. Does > that all make sense? Yes, that makes sense, and I totally agree. We definitely want to keep the other architectures in mind, and hopefully this will be a great tool to help understand any impact there. I expect our changes to cause full-world rebuilds for all architectures, since it requires changes in packages deep in the dependency graph, but none of the changes on wip-ppc64le should break anything for the other architectures. I plan to make a change similar to 53dcca860787ae6cf3949d9c03c0108c47d47c9e, in time. I also want to get Cuirass working at some point soon so we can more easily gauge the health of the nascent powerpc64le-linux port. But for now the most important thing is probably to make the changes that will allow us to build guix-binary.powerpc64le-linux.tar.xz, specifically these three steps: 1) Make changes to guix.m4 etc. so we "officially" support powerpc64le 2) Run make update-guix-package (and commit any changes) 3) Run make guix-binary.powerpc64le-linux.tar.xz That should give us a distributable binary copy of guix to work with, which will be helpful. Right now, I'm just manually running pre-inst-env from a checkout on a Debian ppc64le machine, where I've manually cobbled together the dependencies required to build Guix. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmAfWLYACgkQ3UCaFdgi Rp1FjxAAtN4jIK2n+6FT7EU5WbaYuQW4AuQr+i+Jx2iECJL0yrSEZyXnEgMRofsY n8BBOEjo8y+aFolHO/jVsCQ1hdMoI4FbgpqCJv4Ji6eFDAbm1J1E3GUhAUG/xg/I 5lpwu6ZxCC8h78GY/J5Trbtvk/GBaQ5MGAWJDi13ZpMv/ZG1WozHNQjh9tbfKLDQ 1VjAD9/yzVditXF4uMsECDBdOzwneHLOX2JVlqhqZhoSqQbBPbEOnx1GOzCGgYHg et/VyxhfzJmDS4bLCJzrtdN4gCTWvWE33a93bdl/illpeGzIS7MRb7gbJyb4wy8N pyvzFJACUPWccK0IPeekQTRzaS1MNuWllQw1RWzYrow52e91JA3KjV8Gd3rqwkOu ZKYMVbMDle7WnX3gOj+bzuuPVDJPyuqdMm7L4rvfAJtCWtyw2bUVEz8LSVP8Rud9 ZBZsj3x9RYb7zlulvA7CzedNhTGvNHi+P3f6kBqRydaFFcvtrDMZYsPcMHF78eoz rxIISMTX54sJVTf3y9y/pezC0NFoHhX8Nw0XNB3tlpjC/BFR7yKxU9OhIM5AuPG7 0E9X+gwMl8U5AK+D2SPsl4Wg7SGIKv9zg5LzupoF98luX/0j0eeO/upLX/l4DoMN S8MYH6w97nQeXD6JdXwqlh2EEguMdLgSuhJ6LkHgBZ/KAUrVvR8= =BDy9 -----END PGP SIGNATURE----- --=-=-=--