Chris Marusich <cmmarusich@gmail.com> 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