Re: Workflow preferences - case aarch64 support

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On Mon, Jun 20, 2022 at 01:29:49PM +0300, Ville Ilvonen wrote:
> Hi all,
>
> Good news is that the work on aarch64 support has progressed to the point where
> the Spectrum host can be built natively and run on aarch64 HW.

This is excellent!  Very exciting.

> It's still a bunch of patches in various stages of WIP or review to
> spectrum or further
> up the stream.
>
> In short, to "nixpkgs-spectrum":
> 0001-Allow-static-building-of-dtc.patch
> 0002-Workaround-ld-script-segmentation-fault.patch /* may be not needed */
> 0003-Add-imx8-specific-kernel.patch
> and to "spectrum":
> 0001-Add-imx8-kernel.patch
>
> Should anyone want to reproduce, please let me know and I'll try to
> find a solution
> to share them. Probably worth waiting for cross-compilation support unless you
> have powerful aarch64 at your disposal.
>
> In the meanwhile, we try to establish a mechanism to collaborate in branches of
> required upstream repos. It's fairly impractical to fork
> "nixpkgs-spectrum"-repo due to
> its' size, over 2GB,
>
> Which takes me to the discussion point - what's the workflow proposal
> on multiple people
> working on the same functionality in the same branch? If I'm not
> mistaken the email workflow
> creates a new branch for each author? Then someone would have to
> cherry-pick them to the
> same branch to integrate them in dev time hydra builds.

For that situation, I would recommend having a shared Nixpkgs repository
where the people working on the change can work on it together.  You're
right that Nixpkgs is big, but the bulk of it only has to be pushed
once, and from that point changes will be incremental.  Public git
hosts, if you wanted to use one of those, likely already have somebody's
copy of Nixpkgs on them and might deduplicate against it, so possibly
won't need most git objects to be uploaded anyway.  This is broadly how
feature development works for other projects using similar workflows,
like Linux or QEMU.

When it's time to submit the patches to the list for review, anybody can
do that.  Authorship information is preserved in the patch metadata, so
it's fine for one person to submit a patch series that includes patches
from multiple authors.  git-send-email will also handle automatically
CCing authors on patches that they wrote, so questions / review should
still find their way to the right person.

Does that all make sense?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]