docs: AGENTS.md: never work on main or a release branch, hardware-specific fixes, git identity

This commit is contained in:
theupriser committed 2026-10-01 10:54:49 +02:00
1 parent 71f11a9f8a
commit d354eace93
1 file changed
+16 -1
+16 -1
View File
@@ -48,6 +48,13 @@ gamescope and the Plasma desktop. Primary target: the Valve Steam Machine
`<id>_available` is checked via `component_available` (e.g. `machine` `<id>_available` is checked via `component_available` (e.g. `machine`
only on Fremont). Turn-on order is `COMPONENTS` order, turn-off reverse; only on Fremont). Turn-on order is `COMPONENTS` order, turn-off reverse;
`gaming` must stay first. Dependencies live in `toggle_component`. `gaming` must stay first. Dependencies live in `toggle_component`.
- **Hardware-specific fixes** that belong to a component but aren't a menu
row (e.g. `lib/nvidia.sh`: NVIDIA's kernel parameters and early modules
for gaming mode, called from `gaming_enable`/`gaming_disable`) detect the
hardware themselves, change only what's missing, and undo it on disable.
Add them to the source loop in `steamify.sh` and the table in
`TECHNICAL.md`. They can't be tested without the hardware: say so in the
changelog and keep the branch behind `.no-release-yet` until it was.
- **Feature versions.** Set `FEATURE_VERSION[<id>]` (`lib/menu.sh`) to the new - **Feature versions.** Set `FEATURE_VERSION[<id>]` (`lib/menu.sh`) to the new
`VERSION` whenever what `<id>_enable` sets up changes (a new component gets `VERSION` whenever what `<id>_enable` sets up changes (a new component gets
one too): installs recorded with an older version one too): installs recorded with an older version
@@ -126,7 +133,15 @@ gamescope and the Plasma desktop. Primary target: the Valve Steam Machine
`sudo apt install gh`, then `gh auth login`) instead of working around `sudo apt install gh`, then `gh auth login`) instead of working around
it. Only the it. Only the
release branch's pull request into `main` is the user's: never commit release branch's pull request into `main` is the user's: never commit
or merge to `main`, the user merges that one. or merge to `main`, the user merges that one. Never work directly on
`main` or a `release/*` branch either: edits, even uncommitted ones,
go on a `feature/`/`bugfix/` branch (create it before editing; the
release branch only gets the version-bump commit and merged PRs).
Don't push a new `release/*` branch before it's needed: a push can
start CI builds (a dev ISO).
A machine without a git identity: pass the repo's author per command
(`git -c user.name=... -c user.email=... commit`, taken from `git
log`) instead of changing the git config.
A `.no-release-yet` file at the root of a feature/bugfix branch means A `.no-release-yet` file at the root of a feature/bugfix branch means
it must not be merged into the release branch yet (work in progress, it must not be merged into the release branch yet (work in progress,
untested on hardware). When the feature is complete, ask the user untested on hardware). When the feature is complete, ask the user