The omega8cc fork model

Every Aegir-layer component BOA installs is an omega8cc repository, cloned from _gitHub="https://github.com/omega8cc" (BARRACUDA.sh.txt:183, OCTOPUS.sh.txt:184). These are not tracking forks: they diverged substantially and deliberately years ago, and omega8cc is the upstream of record for all of them. There is no rebase-from-upstream workflow, no upstream remote worth fetching, and no path by which a pre-fork release ever reaches a BOA box. A fix for a fork bug lands in the fork — filing it against a pre-fork project (aegir-project on drupal.org/GitLab, drush-ops/drush) parks it where no BOA code will ever pick it up.

The repositories

All fetched by the twin staging builders — _master_download_for_local_build (master.sh.inc:547) and its intentionally duplicated satellite copy (satellite.sh.inc:3125; the master/satellite pair is mirrored per file, never DRYed) — or by _provision_backend_up (master.sh.inc:656):

Auxiliary Drush extensions ride along in the same backend fetch (master.sh.inc:689-699): drupalgeddon, drush_ecl, registry_rebuild, safe_cache_form_clear, clean_missing_modules, utf8mb4_convert into ~/.drush/usr/, and security_review, provision_boost into ~/.drush/xts/. These are omega8cc-hosted pins of Drupal-contrib projects at 7.x-* branches — maintained under omega8cc like everything else, but thin pins rather than heavily diverged forks.

The drush repo also carries 10-boa-micro through 13-boa-micro branches for modern platforms; BOA installs the 10/11 lines version-pinned (_DRUSH_TEN_VRN=10.6.2, _DRUSH_ELEVEN_VRN=11.6.0, BARRACUDA.sh.txt:48-49) at /opt/tools/drush/{10,11}/ with /usr/bin/drush10 / /usr/bin/drush11 symlinks (system.sh.inc:3914,3934). The Aegir backend itself runs only the Drush 8 line.

The make chain

The Hostmaster platform is assembled by drush make from a local staging directory, never from drupal.org downloads:

_master_download_for_local_build (master.sh.inc:547)
   clones the forks above into /opt/tmp/make_local/
      ↓
provision/aegir.make          — Drupal core + hostmaster profile,
                                both download[type]="copy" from make_local (aegir.make:7-14)
      ↓
hostmaster/hostmaster.make    — eldir, hosting, and the hosting_* satellites,
                                same copy-from-staging pattern (hostmaster.make:11-17;
                                drupal-org.make:141-143 for hosting_custom_settings)
      ↓
drush hostmaster-install ${_DOMAIN} … --root=${_HM_ROOT} --http_service_type=nginx
                              (satellite.sh.inc:5734, dup at 5749)

Just before the build, the installer rewrites files.boa.io to the selected mirror inside ~/.drush/sys/provision/aegir.make (satellite.sh.inc:5664 — sed -i "s/files.boa.io/${_USE_MIR}/g"). Changing what ships in the platform therefore means touching two repos: the fork that carries the code, and the make/staging wiring (hostmaster.make or drupal-org.make plus the _*_download_for_local_build clone list — both copies).

Where the forks land on a box

~ is /var/aegir on the master instance and /data/disk/<user> on each Octopus satellite. The Drush-extension layout is ~/.drush/{sys,usr,xts}/, not bare ~/.drush/:

The sys/usr/xts split is a trust boundary, not tidiness. The drush fork ships includes/boa_extension_filter.inc, which default-denies *.drush.inc auto-loading from BOA tenant-writable paths and trusts the BOA-managed .drush/{sys,usr,xts}/ subtrees plus /var/aegir/; it is wired into all three discovery call sites (includes/command.inc::_drush_add_commandfiles(), includes/annotationcommand_adapter.inc, includes/preflight.inc). Backend code installed outside the split both drifts from the layout every installer re-enforces and steps outside the filter's trusted set — put new backend extensions under the correct subtree, and mirror any layout change into the filter's trust rules.

Divergence policy

Divergence is one-way and permanent. Working rules:

• Fixes land in the fork. Even when a bug demonstrably predates the fork point, the fix is committed to the omega8cc repo. There is no "report it upstream and wait" path — the pre-fork projects are neither watched nor merged from.
• Pre-fork docs are background, never authority. Anything they say about paths, branches, packaging (apt install aegir3-*, drupal.org release flow) is wrong on BOA; verify against fork source before reusing a claim.
• Fork-only surface is normal, not exceptional. Representative examples: the drush extension filter above (exists nowhere upstream); the Drush 8 line continued past the final pre-fork 8.4.x releases under the fork's own 8.5.x numbering (pin 8.5.4, BARRACUDA.sh.txt:50); the make chain rewired from drupal.org downloads to staging copies (hostmaster.make:11-17).
• Nginx is the only exercised web service. BOA renders every vhost through provision's Nginx config classes (nginx.sh.inc:193, nginx.sh.inc:1001-1010 operate on .drush/sys/provision/http/Provision/{Config/Nginx,Service/http}/). The Apache service classes still present in the provision tree (http/Provision/Service/http/apache/, http/Provision/Config/Apache/) are pre-fork residue: unexercised, unmaintained, and left in place per the keep-harmless-residuals policy — do not build on them, and do not spend a cleanup commit deleting them.
• Mind the compatibility floor. The Drush 8 fork declares "php": ">=5.4.5" (drush composer.json:36) and stays runnable on the old CLI PHP found on legacy boxes; do not modernise its syntax — or that of the provision/hosting PHP it loads — past that floor. Details in Code style & conventions.

How the forks ride the release train

Each BOA release tree stamps itself: export _tRee=dev on the 5.x-dev branch (BOA.sh.txt:47), _tRee=lts on 5.x-lts, _tRee=pro on 5.x-pro. Every fork clone line resolves 5.x-${_tRee}, so a box on a given tree checks out the matching fork branch family — hosting and provision publicly carry 5.x-dev, 5.x-lts, 5.x-pro (plus 5.x-head and 5.x-lite), and every fork must publish whichever 5.x-<tree> branch the clone line will ask for. Provision alone uses the separate _BRANCH_PRN pin instead of the literal 5.x-${_tRee} template, so a tree can pin its provision revision independently.

Branches are only half the story. The default install path is _DL_MODE=BATCH (barracuda.sh.cnf:349, octopus.sh.cnf:210): production boxes never touch GitHub, they fetch tree-stamped tarball snapshots — make_local.tar.gz (master.sh.inc:563, satellite.sh.inc:3142), backend.tar.gz (master.sh.inc:667, satellite.sh.inc:5617), drush-${_DRUSH_VERSION}.tar.gz (i.e. drush-8.5.4.tar.gz, master.sh.inc:735) — all via _get_dev_ext (helper.sh.inc:259), which pulls from ${_urlDev}/${_tRee}/ = <mirror>/dev/${_tRee}/ (_urlDev, barracuda.sh.cnf:1409). _DL_MODE=GIT clones the forks live from github.com/omega8cc and is the maintainer/debug path. Consequence for any fork fix: merging to the fork branch does not deploy anything. The fix reaches fleets only when the release pipeline rebuilds the tarball snapshots for the tree and the serial gates force a re-fetch (compare the .ctrl.${_tRee}.${_xSrl}.pid stamp guarding /opt/tools/drush/8, system.sh.inc:4008-4011). The full mechanics — the 5.x-dev/-base/-edge → 5.x-pro*/5.x-lts* promotion flow, tags on pro/lts, and the SKYNET self-update agent — are covered under Release model & SKYNET, specifically The serial & fetch pipeline.

Related

• Stack architecture — the entry-script chain and lib/functions/*.sh.inc include sets the fork fetchers live in.
• Contributing to BOA — where to file issues and PRs against the forks.
• Code style & conventions — bash and PHP rules, including the legacy-PHP floor for backend code.
• Variables — _VAR reference for the pins and toggles cited here (_DL_MODE, _DRUSH_*_VRN, _BRANCH_*).
• Discontinued features — components that left the stack; check before documenting anything found only in old trees.