Re: Branch management, wip-ppc64le, and POWER9

[Chris Marusich]

Hi,

Christopher Baines <mail@cbaines.net> 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 <leo@famulari.name> 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 <mail@cbaines.net> 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

signature.asc
Description: PGP signature