doxa-life/doxa-maps
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

README: the cloud paragraph says why one pilot server per app, and names the landing rebuild from accepted pull requests as planned too

Browse source
This commit is contained in:
Doxa Maps 2026-10-02 05:31:23 +00:00
parent 919f5fa46e
commit dceb824e3f
1 changed files with 7 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
README.md
View file

@ -762,9 +762,13 @@ gate-keeper that reads each change before it lands, are jobs your harness gives
Keep the repository on a forge you host yourself: a swarm pushes often, and on a public host one wrong
push publishes work you did not mean to share. Give each app two servers: a **pilot server** that
follows the pilot branch with hot reload, and a **landing server** that rebuilds from the landing
branch. The cloud container in `deployment/cloud/` runs both today. Planned, not built yet: a pilot
server that can be switched to show a single PR branch, with a table of PR branches under it, so a
team can look at one feature together before it lands.
branch. The cloud container in `deployment/cloud/` runs both today. One pilot server per app, rather
than one per pull request, keeps the memory the same however many pull requests are open. Each
developer can still build on their own machine with the Plugin Studio and push their branch.
Planned, not built yet: switching the pilot server to show one pull request at a time (with a table of
the open pull requests under it), and rebuilding the landing branch from the accepted pull requests in
order, so a rejected one is simply left out of the next rebuild.
How to contribute, and the bar for shared code: [documentation/CONTRIBUTING.md](./documentation/CONTRIBUTING.md).
Taking contributions from a contributor's own forge into your GitHub repository: [documentation/contribute/TUTORIAL.md](./documentation/contribute/TUTORIAL.md).