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 cJC3LsvAG2BQSgAA0tVLHw (envelope-from ) for ; Thu, 04 Feb 2021 09:39:23 +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 WM9dKsvAG2CARwAAB5/wlQ (envelope-from ) for ; Thu, 04 Feb 2021 09:39:23 +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 E2E9D9402C8 for ; Thu, 4 Feb 2021 09:39:22 +0000 (UTC) Received: from localhost ([::1]:43654 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7b6f-0007QL-P1 for larch@yhetil.org; Thu, 04 Feb 2021 04:39:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7b6J-0007Ku-Hc for guix-devel@gnu.org; Thu, 04 Feb 2021 04:38:59 -0500 Received: from mira.cbaines.net ([2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27]:45141) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7b6D-0007Rf-Sg for guix-devel@gnu.org; Thu, 04 Feb 2021 04:38:59 -0500 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:8ac0:b4c7:f5c8:7caa]) by mira.cbaines.net (Postfix) with ESMTPSA id AE32927BC1F; Thu, 4 Feb 2021 09:38:46 +0000 (GMT) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id e2ee8955; Thu, 4 Feb 2021 09:38:46 +0000 (UTC) References: <87k0romcrz.fsf@gmail.com> User-agent: mu4e 1.4.14; emacs 27.1 From: Christopher Baines To: Chris Marusich Subject: Re: Branch management, wip-ppc64le, and POWER9 In-reply-to: <87k0romcrz.fsf@gmail.com> Date: Thu, 04 Feb 2021 09:38:43 +0000 Message-ID: <877dnoyxy4.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27; envelope-from=mail@cbaines.net; helo=mira.cbaines.net 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: , 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: -4.46 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-Migadu-Queue-Id: E2E9D9402C8 X-Spam-Score: -4.46 X-Migadu-Scanner: scn1.migadu.com X-TUID: 7rK32GBc2zcQ --=-=-= Content-Type: text/plain Chris Marusich writes: > Since I'm now making commits on wip-ppc64le to add support for POWER9 > machines like the Talos II and Blackbird from Raptor Computing Systems, > I'd like to understand more about how I am expected to manage that > branch. Before I touched it, it sat with just one lonely commit, > essentially unused. So it seems to me like I'm not stepping on anyone's > toes, and that I should just make commits like I normally would on > master, staging, or core-updates, being careful to follow the usual > guidelines. > > Specifically, I'm curious to know: > > - Is it usually expected that wip branches can be rebased? I don't plan > to rebase wip-ppc64le, since I'd like to be able to coordinate with > others using this branch, but I'm not sure what others expect. 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. > - Should I just periodically merge from master, or perhaps core-updates, > to keep wip-ppc64le up to date and resolve conflicts early? I've > already merged master into this branch once, to get it back up to > date. I haven't merged core-updates into it yet. I think > periodically merging branches into wip-ppc64le is the right thing to > do, since eventually the end goal will be to merge wip-ppc64le into > core-updates to get POWER9 support into a release. However, I suppose > if I merge from different branches, I could wind up dealing with > unnecessary conflicts. core-updates is pretty broken at the moment (building the channel derivation fails), so I wouldn't recommend that. 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. 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. > - 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=wip-lle-bout-le1&id=53dcca860787ae6cf3949d9c03c0108c47d47c9e 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? Thanks, Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmAbwKNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XfgYxAAtt9V7pRw7zsYLIHanHVs9AagiEu3DtbO 6b4DoL5vjIYuX70GTTot+YZNBsnngcUhb2M15H22IZa9vOycoK46KQ1qYmbY/ET4 2qbNpk/71yj6pfYy9iBGDjR68mYQDPx1j+LNRudhcBLT3uLxheZhFxsUB4QnDAo+ xef1OA8YPj3bzrmG6zflVmRxx9T4yno8FgxnJU3xQWXPdkmWXrRLqtGXt0ffdn9l xwO5SDcCfgkV1BL/L/1J+5dP37bCk0JeintFYstg0aLYYEy5uB/S1QDNDRGNjZZk 0853lYIq03n/NtvkbqpsugkiUSAdy3iTK/uy/rNzJQ5OtAePYDfGMJqCZlCPAT06 xpEsmz903lyCdQCgzQ9sBd8Sk8vszJ2QyDVTe9zpLKytzknCmlkA4Uia0p4CsQST EFAE/mYvVp3y0R1MHJRbM4CAwxGDRIBD58jlIyAed1FslE6R2Aak11XYR5OF/mzg EIMzaZMvXxEWjUnU5ig6sQAedh1dQ7AHtqhwqYBfRH8Yy2AapOAwCyAYtWAFE35i EYzQG2pjU1K2DMA9SugT7gelx2B9ClT4IplAyntTqHkAGkxywMOzT3lAUN2ZXeaZ LgTxNL1EuueecDePzGPFdkJ01uQ+Jd3cv9dcOJi6EiSBRpvZiJHgb3pXENmDGF+a qjDvk9Wxa0A= =jyiO -----END PGP SIGNATURE----- --=-=-=--