Skip to content

Friend repos, monthly activity digests

Monthly logs of what shipped on related open-source LED projects — the live landscape projectMM watches to sharpen its own designs under the Industry standards, our own code principle (CLAUDE.md § Principles): study to think, write fresh, never copy. Generated by the digest prompt below.

  • FastLED-FastLED.md — the LED-animation library; ESP32/Arduino driver + color math.
  • wled-WLED.md — upstream WLED firmware.
  • MoonModules-WLED-MM.md — MoonModules' WLED fork (the direct lineage).
  • troyhacks-WLED.md — troyhacks' personal fork of WLED-MM (PixelForge, RMTHI, audio-reactive hardening).
  • Funkelfetisch-projectMM.md — a fork of THIS project building a commercial product on it (HELIO, a physical infinity-sphere lamp); the work lives in feature branches, not on its default branch.
  • PlummersSoftwareLLC-NightDriverStrip.md — Dave Plummer's LED matrix/strip firmware.
  • hpwit-I2SClocklessLedDriver.md — hpwit's I2S/LCD DMA clockless LED driver (parallel multi-strip output).
  • hpwit-I2SClocklessVirtualLedDriver.md — the shift-register "virtual pins" variant of the above (dormant since 2024).
  • hpwit-ESPLiveScript.md — hpwit's live C-like script compiler for the ESP32 (main quiet; work moved to version branches).
  • hpwit-new-parser.md — ESPLiveScript2, hpwit's from-scratch rewrite of the above (repo is named new-parser; the library lives in asmparser2/). Dormant May 2025 → August 2026, then an active rewrite whose stated goal is a verifiable compiler: host builds plus QEMU running the actual compiled Xtensa bytes.

Digest prompt (reusable)

Friend-repo monthly digest. For the repo <NAME> (local clone at <PATH>, or via gh api repos/<owner>/<NAME>), summarise what landed on its main/default branch during <MONTH YEAR>.

  1. Read the merged commits on the default branch with author-date in that calendar month (git log --first-parent --since/--until on the local clone, or the GitHub API). Use --first-parent so it's the merged-feature view, not every squashed sub-commit. The default branch isn't always main/master — check (git remote show origin); e.g. WLED-MM's is mdev. 1b. Also investigate the issues over that month. The REST gh api repos/<owner>/<NAME>/issues endpoint returns pull requests too — filter them out (--jq '.[] | select(.pull_request == null)') or use the GitHub search API, which already excludes them: search/issues?q=repo:<owner>/<NAME>+is:issue+created:<YYYY-MM-DD..YYYY-MM-DD> (and the same with closed:). Only real issues, not PRs. The commit log shows what shipped; the issues show what users hit and what the maintainers are prioritising — the two together are the real activity picture. Skim: notable bugs opened (recurring pain points, hardware quirks), fixes closed that map to a commit, and any heavily-discussed feature request or design thread. Fold the user-facing ones into the summary below (a widely-reported bug that got fixed, a feature the community is pushing for); an issue with no user-facing outcome yet is still worth a one-line "watching:" note if it signals a direction. Don't list every issue — surface the few that matter, the same bar as the commit summary.
  2. Split a month at any release boundary — but only if the release was cut from the branch you're summarising. If a versioned release was published mid-month (check git for-each-ref refs/tags / the GitHub releases API; ignore rolling tags like nightly and prereleases), AND the tag is an ancestor of the digest branch (git merge-base --is-ancestor <tag> <branch>), split that month at the release date into ## <Month Year> (up to v<X>) / ## <Month Year> (post-v<X>). If the tag is NOT an ancestor (the project cuts releases from a separate release branch — e.g. upstream WLED tags off 0_15/release branches, not main), do NOT split: keep the month whole and just note which release shipped that month as context, since the trunk you're summarising feeds future releases rather than being the release line. Whole months with no in-branch release stay one section.
  3. Write an end-user-readable summary: what changed that a user of the library would notice or care about — new features, new hardware/platform support, notable fixes, breaking changes. Skip internal refactors, CI, test-only, and dependency bumps unless they affect users.
  4. Format as short bullet points, each one line, plainest language, minimal jargon. Group only if there's a natural split (e.g. "New" / "Fixed"); otherwise a flat list.
  5. Add it as a ## <MONTH YEAR> section to docs/friend-repos/<NAME>.md, newest month on top. Don't editorialise or compare to projectMM — just report what they shipped.
  6. State the commit range / count and the issue query summarised so the digest is auditable.

When backfilling several months (e.g. since the last release), run this once per month for a consistent timeline, then optionally add a ## Since v<last-release> — overview intro at the top with 3–5 bullets naming the multi-month threads the per-month slices can't show on their own.