ten answers done: R-444 seen working live (weekly trim + System page), closed; STATUS, CONTEXT, REPORT (150 -> 142; 2 opened, 10 closed)
gates / gates (push) Successful in 2m44s
gates / gates (push) Successful in 2m44s
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
This commit is contained in:
@@ -2,8 +2,25 @@
|
||||
|
||||
**Ready for the first real tester (Tester-2): yes. Tester 2 (a laptop) is off; nothing was sent to it.**
|
||||
|
||||
**Updated 2026-10-06 09:00: every box of ours healthy on hub 0.138.0, agent 0.148.0, controller 0.299.0; installer 1.32.0
|
||||
is public. The open-items list is at 150. Report: `REPORT-morning-after-2026-10-06.md`.**
|
||||
**Updated 2026-10-06 13:15: every box of ours healthy on hub 0.139.0, agent 0.149.0, controller 0.300.0. The open-items
|
||||
list is at 142. Report: `REPORT.md`.**
|
||||
|
||||
## Midday (2026-10-06): your ten answers built; the list at 142
|
||||
|
||||
- **All ten are done** (your „A" on each). Released to demo-hp, demo-felhom and Tester 1: hub 0.139.0, agent 0.149.0 (and
|
||||
its root files), controller 0.300.0 and a new install image.
|
||||
- **The weekly disk trim works:** measured by hand first (the disk pool went from 65 % to 33 % full, the apps did not
|
||||
notice), then the box's own weekly job trimmed by itself, and the System page shows it.
|
||||
- **No broken backup leftovers exist on the backup server today**, so nothing was deleted. The steps are written down
|
||||
for the day one appears.
|
||||
- **Three of your answers differed from my picks (2, 8 and 9).** Your answer governs, and each is recorded.
|
||||
|
||||
**Needs you (none urgent):**
|
||||
1. **R-890** — a vaultwarden update can still not be written to the update list: the list needs a proof on the scratch box
|
||||
too, and your ruling keeps the admin password on the test bench only. Pick: allow it on scratch box 9202 as well. If
|
||||
nothing: vaultwarden updates stay manual.
|
||||
2. **R-891** — one line in felhom.eu `CLAUDE.md` is now untrue (it says the quick test run covers every check; the new ISO
|
||||
test runs only in full runs). Only you may edit that file.
|
||||
|
||||
## This morning (2026-10-06): your two answers done; the list at 150
|
||||
|
||||
@@ -13,21 +30,6 @@ is public. The open-items list is at 150. Report: `REPORT-morning-after-2026-10-
|
||||
- **The four waiting app fixes passed on the scratch box and are live** (visitor addresses for kimai, zipline, vikunja,
|
||||
nextcloud; nextcloud's health check). Each was tested against a control.
|
||||
|
||||
## Ten questions for you — answer „all as picked", or name the ones you want differently
|
||||
|
||||
| # | Question | Option A | Option B | If you decide nothing | My pick |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | **R-444** — Should the boxes trim their customer guests' disks once a week, so deleted data stops filling the disk pool? | Yes: one new admin permission (`pct fstrim`), weekly, outside the night, measured once on demo-hp first | No: leave it; the pool keeps space nobody uses | Nothing changes; a full pool can one day stop every guest on that box | **A** |
|
||||
| 2 | **R-99** — Should broken leftovers of aborted backups be deleted on the backup server? | Yes, by hand, by a runbook, when one is seen | No: they are detected, harmless, and do not affect what is kept | They stay; one small leftover per aborted upload | **B** |
|
||||
| 3 | **R-618** — May an app update count Docker's own „healthy" as proof that the new version works? | No: keep our own check only | Yes: Docker's healthy can end a wait early | Nothing changes (A) | **A** |
|
||||
| 4 | **R-645** — When you lift a held update by hand, how do we stop the night backup from saving the broken version over the good copy? | The night backup skips an app whose saved version is not what it runs | Lifting a hold by hand is refused; you use „Undo" instead | The good copy can be overwritten within seconds of a hand lift | **A** |
|
||||
| 5 | **R-856** — After a crash restart, should app mails wait longer (about 15 minutes), so the household gets one message, not three? | Yes: a longer quiet time after a crash boot (two repositories change) | No: close it; one crash can send several true mails | Several mails after a crash, as now | **A** |
|
||||
| 6 | **R-747** — Should mealie's app page tell the household that five wrong logins lock the account for 1–2 hours? | Yes: one sentence on the page | No | A locked household does not know why or for how long | **A** |
|
||||
| 7 | **R-734** — Should the update test ignore small marker files an app rewrites at every start (immich)? | Yes: a per-app list of such files, each with a reason | No: keep marking it; immich updates then need a fresh full copy first | immich's night update is skipped where no fresh copy exists | **A** |
|
||||
| 8 | **R-624** — May the update test hold an app's admin password to create test data in apps that refuse strangers (vaultwarden, zipline)? | Yes, on the test bench only | No: write down that these apps are tested by hand | No change; those two apps stay hand-tested | **B** |
|
||||
| 9 | **R-502** — May a slow check that starts Docker containers run on DooPlex (the ISO's first-boot test)? | Yes, in full runs only (never on every push), with a clear „not checked" when Docker is missing | No: it stays a hand step of each ISO release | It stays a hand step; it can be forgotten | **B** |
|
||||
| 10 | **R-774** — Should Karakeep's page say that its phone app sends crash reports to its makers? | Yes: one sentence on the page | No | The household is not told | **A** |
|
||||
|
||||
## Tonight (2026-10-06): the list at 164
|
||||
|
||||
**What happened:** 36 rows closed, 1 opened. Released and delivered the normal way to demo-hp, demo-felhom and Tester 1:
|
||||
|
||||
Reference in New Issue
Block a user