Keep Flatpak packaging canonical in Flathub repo.
Use automatic update PR creation plus automatic merge/publication.
Treat Flatpak verification as packaging/sandbox sanity checks only; runtime/device validation remains manual/
out-of-band.
Expected update availability remains: usually within hours after upstream release (checker cycle + build/
publish + client refresh cadence).

Key Decisions (Locked)

Manifest ownership: Flathub app repo only.
Release automation: full auto-merge for bot-generated update PRs.
Testing policy: no device/runtime CI gate; manual real-device checks only when you choose to run them.

Public Interfaces / Metadata

Define app ID (e.g. in.skobkin.MeshGo).
Provide in Flathub repo:
- .yml manifest
- .desktop
- .metainfo.xml
- icons/screenshots required by Flathub/AppStream
Declare only required Flatpak permissions (network/serial/bluetooth/filesystem as needed).

Implementation Plan

Prepare metadata and permissions

Create desktop/AppStream metadata (currently absent).
Audit runtime permission needs from app behavior and lock minimal finish-args.

Submit to Flathub

New app PR via Flathub submission flow.
Iterate on review feedback until app is accepted and app repo is active.

Configure automated updates

Enable External Data Checker in manifest.
Configure repository/branch protection to allow trusted bot update PRs to auto-merge after required checks.
Keep required checks minimal and packaging-focused (manifest validity/buildability), not device-runtime tests.

Define operational guardrails

Auto-merge default for version bumps/source hash updates.
Require manual intervention only for:
- permission changes
- runtime/SDK jumps
- structural manifest changes
Document emergency rollback flow (revert in Flathub repo).

Testing and Acceptance

Required automated checks:
- manifest parses and builds in Flatpak environment
- metadata validation passes
Explicitly out of CI scope:
- Meshtastic device integration tests
- GUI behavior with live hardware
Acceptance criteria:
- App installs/launches from Flathub
- New upstream release triggers automated Flathub update and publication without manual action

Timeline and Update Latency

Initial app onboarding: typically days to weeks (review queue and fixes).
Ongoing updates:
- release detection typically within ~2 hours
- plus Flathub build/publish processing
- plus user-side refresh cadence
Practical target: same-day availability for most releases.

Assumptions

Upstream releases/tags are consistent and machine-detectable.
You accept occasional bad upstream release risk in exchange for speed.
Device/runtime validation remains a manual process outside Flathub CI.

## Flathub Plan (Updated for Headless CI + Auto Publication) 05:27 [13/308] ### Summary - Keep Flatpak packaging canonical in Flathub repo. - Use automatic update PR creation plus automatic merge/publication. - Treat Flatpak verification as packaging/sandbox sanity checks only; runtime/device validation remains manual/ out-of-band. - Expected update availability remains: usually within hours after upstream release (checker cycle + build/ publish + client refresh cadence). ### Key Decisions (Locked) - Manifest ownership: Flathub app repo only. - Release automation: full auto-merge for bot-generated update PRs. - Testing policy: no device/runtime CI gate; manual real-device checks only when you choose to run them. ### Public Interfaces / Metadata - Define app ID (e.g. in.skobkin.MeshGo). - Provide in Flathub repo: - <app-id>.yml manifest - <app-id>.desktop - <app-id>.metainfo.xml - icons/screenshots required by Flathub/AppStream - Declare only required Flatpak permissions (network/serial/bluetooth/filesystem as needed). ### Implementation Plan 1. Prepare metadata and permissions - Create desktop/AppStream metadata (currently absent). - Audit runtime permission needs from app behavior and lock minimal finish-args. 2. Submit to Flathub - New app PR via Flathub submission flow. - Iterate on review feedback until app is accepted and app repo is active. 3. Configure automated updates - Enable External Data Checker in manifest. - Configure repository/branch protection to allow trusted bot update PRs to auto-merge after required checks. - Keep required checks minimal and packaging-focused (manifest validity/buildability), not device-runtime tests. 4. Define operational guardrails - Auto-merge default for version bumps/source hash updates. - Require manual intervention only for: - permission changes - runtime/SDK jumps - structural manifest changes - Document emergency rollback flow (revert in Flathub repo). ### Testing and Acceptance - Required automated checks: - manifest parses and builds in Flatpak environment - metadata validation passes - Explicitly out of CI scope: - Meshtastic device integration tests - GUI behavior with live hardware - Acceptance criteria: - App installs/launches from Flathub - New upstream release triggers automated Flathub update and publication without manual action ### Timeline and Update Latency - Initial app onboarding: typically days to weeks (review queue and fixes). - Ongoing updates: - release detection typically within ~2 hours - plus Flathub build/publish processing - plus user-side refresh cadence - Practical target: same-day availability for most releases. ### Assumptions - Upstream releases/tags are consistent and machine-detectable. - You accept occasional bad upstream release risk in exchange for speed. - Device/runtime validation remains a manual process outside Flathub CI.

skobkin pinned this

2026-02-13 07:36:41 +03:00