Plans and investigations for the Gershwin desktop — the GNUstep-based, Apple-style userland that runs on FreeBSD, NextBSD, and Linux. Installer, live-ISO, and component work for gershwin-desktop/gershwin-components and friends.
installer-linux.sh drifted from source and lost --check-image-source (so the image radio never appears), image detection only matches iso9660 (misses Debian’s /run/live/medium), and the clone path installs the bootloader via chroot grub-install/update-grub which needs grub+initramfs inside the copied tree (FreeBSD instead copies loader.efi + efibootmgr). Also surfaces a latent NextBSD bug: the ostype rebrand makes the boolean IAIsFreeBSD() misclassify NextBSD as Linux. Plan: a dispatcher + per-OS modules with proper names (out of the /System/Library/Scripts junk drawer), an explicit --method flag, a 3-way platform resolver, a first-class NextBSD backend (launchd, label-based UFS ROOTFS, kextd autoload, configd/hostnamed identity), and a shared first-boot identity reset (machine-id, SSH host keys, stable fstab).
Copier.framework
Replacing the shell file-walker with a native Objective-C copier framework for the clone/image pipeline.
make check) cover unit/integration; StepTalk and Distributed Objects are functional/integration drivers that script a running app; UI/acceptance/visual-regression have no native tooling because GNUstep’s NSAccessibility is a stub with no AT-SPI bridge (so LDTP/Dogtail are blocked and “read the screen” is a pixel/OCR problem). Documents how the gershwin-on-nextbsd QEMU screenshot gate works today (monitor sendkey/screendump + colour-count + tesseract OCR, gating publish). Proposes a native Gherkin/BDD framework (Frank/Calabash-style in-app TestAgent that walks the view tree — routing around the missing a11y — driven by godog), and a full-pyramid strategy that runs in GitHub Actions and locally.
gershwin-on-{debian,freebsd,arch,devuan,nextbsd} collapse into gershwin-desktop/gershwin-desktop? A 3-agent live read of all five repos, the shared checkout.sh, the release inventory, and GitHub’s 2026 limits. Finds two build families (Linux-container vs FreeBSD-VM) that want two reusable workflows, not one matrix; NextBSD’s QEMU boot+colour-count+OCR screenshot test is the gate to spread to every target (release needs: [build, test]). Real constraints are the 2 GiB-per-asset cap (Arch already at 1.91 GiB) and the one-time history migration — not storage (release assets are unquota’d) or concurrency (the 20-job ceiling is already org-wide across all five repos, so mono vs split is a wash). Answers the rolling-tag question directly: per-target continuous-<distro> tags, ~10–15 GiB live, self-cleaning once every target moves off uploadtool to gh release delete+create (which is what’s letting Devuan’s tag leak today). Plus the ~15-line checkout.sh custom-branch change that unblocks the future second job, and a 3-way alternatives table (monorepo / hub-repo / unified dispatcher) with a de-risked rollout order.