Workflow preferences - case aarch64 support
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. 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. Best, -Ville
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?
participants (2)
-
Alyssa Ross
-
Ville Ilvonen