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=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? 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. -- Chris