scylladb Weekly Commit Summary
Generate curated weekly commit summaries that highlight changes important to SCT developers and testers.
Essential Principles
Curate, Don't Dump
Select commits that matter to other developers, not every change that landed.
The raw git log contains dozens of commits. Most are routine fixes or dependency bumps that don't need attention. The summary exists to surface changes that affect how people write tests, use tools, or understand the framework. Including everything defeats the purpose — readers stop reading.
Embed Links in Context
Links belong inside the most meaningful phrase of each paragraph, not at the start.
Readers scan by link text. A link on "was updated" tells nothing; a link on "migrated from dict-based to pydantic configuration" tells the whole story. Vary link placement — don't start every paragraph with a link, because it creates a monotonous list feel.
Group Related, Pick the Notable Ones
Combine commits that touch the same area into one paragraph, but do not cover every commit in the group — pick only the most notable ones.
Two commits updating scylla-bench belong together. A scylla-bench update and a new nemesis do not. When a PR or refactor lands as 5–10 small commits, do not link each one. Describe the change as a whole and link 1–3 of the most representative commits (the one that introduces the feature, plus a follow-up fix or the final shape). Mixing unrelated changes forces readers to context-switch mid-paragraph; listing every commit in a group turns the paragraph into a changelog dump.
Follow the Established Voice
Match the tone and structure of previous issues — concise, factual, third-person. Describe what changed, never who changed it.
The report has a consistent voice across 100+ issues. Do not attribute work to authors by name — write "SCT gained X" or "the Y pipeline was fixed", never "Alice landed X" or "Bob refactored Y". Author attribution is already available via the commit link; naming authors in prose creates bias and reads like a team newsletter. The opening and closing lines are fixed templates.
When to Use
- When asked to generate a weekly commit summary or "last week in SCT" report
- When asked to create a new commit summary issue
- When asked to curate or filter commits for a summary report
- When asked to write up recent SCT changes for the team
- When incrementing the commit summary issue number
When NOT to Use
- For regular git log viewing or commit history exploration
- For writing changelogs for releases (different format and audience)
- For reviewing a specific PR or set of changes
- For generating commit messages (that's a different task)
What to Include vs. Exclude
| Include | Exclude |
|---|---|
| New tests or test categories added | Small bug fixes with narrow scope |
| Stress tool or driver updates (ScyllaDB-maintained: scylla-bench, latte, gemini, cassandra-stress, scylla-driver, argus, YCSB) | General package/dependency bumps (renovate, pip updates) |
| Bigger refactorings that change how code is organized | Minor refactors (rename, move, cleanup) |
| New implementation plans | Hydra/container image updates |
| New framework capabilities or backends | Typo fixes, formatting changes |
| Configuration system changes | CI pipeline tweaks (unless significant) |
| Monitoring or reporting improvements | Merge commits (already excluded by script) |
| Nemesis additions or major nemesis changes | Pre-commit hook minor adjustments |
| Performance test additions or changes | |
| Cloud backend additions (OCI, xcloud, etc.) |
Quick Reference
Determine Next Issue Number and Start SHA
Find the latest commit_summary_issue_*.md file. The issue number increments by 1. The start SHA is the end commit from the previous report's second line (after the ... in the commit range).
Generate Raw Commit List
The script is bundled at skills/commit-summary/sct_commits_summary.py:
python3 skills/commit-summary/sct_commits_summary.py <start_sha> > commit_summary_issue_<N>.md
Fetch Upstream Release Notes for ScyllaDB Tools and Drivers
When a commit bumps a ScyllaDB-maintained tool or driver, a renovate commit title like update dependency X to vY.Z does not tell the reader what changed. Fetch the upstream release notes via gh release view and pull in the 1–3 most relevant items (bug fixes, new features, behavior changes) to enrich the paragraph.
Repository and tag mapping:
| SCT dependency | Upstream repo | Tag format |
|---|---|---|
| scylla-bench | scylladb/scylla-bench |
vX.Y.Z |
| scylla-driver (Python) | scylladb/python-driver |
X.Y.Z-scylla |
| gemini | scylladb/gemini |
vX.Y.Z |
| latte | scylladb/latte |
vX.Y.Z |
| cassandra-stress | scylladb/cassandra-stress |
branch/tag varies |
| argus | scylladb/argus-client |
vX.Y.Z |
| YCSB | scylladb/YCSB |
scylla-X.Y.Z |
| scylla-manager | scylladb/scylla-manager |
vX.Y.Z |
| scylla-doctor | scylladb/scylla-doctor |
vX.Y.Z |
Command:
gh release view <tag> --repo scylladb/<repo>
If the exact tag is not found, list recent releases first:
gh release list --repo scylladb/<repo> --limit 10
Use the release notes only to enrich the prose describing what changed. Do not embed links to other repositories (no upstream commit, PR, or release-tag links) — the only link in the paragraph must be the SCT commit that performed the bump. Summarize the 1–3 most relevant highlights in plain prose (e.g. "a libev segfault fix on shutdown, a RecursionError fix in execute_concurrent, and AWS PrivateLink support").
Output Template
The final report follows this exact structure:
This short report brings to light some interesting commits to [scylla-cluster-tests.git master](https://github.com/scylladb/scylla-cluster-tests) from the last week.
Commits in the <start_8chars>...<end_8chars> range are covered.
There were N non-merge commits from M authors in that period. Some notable commits:
<curated paragraphs with embedded links>
See you in the next issue of last week in scylla-cluster-tests.git master!
Reference Index
| File | Content |
|---|---|
| writing-style.md | Detailed style patterns with good/bad examples extracted from past issues |
| Workflow | Purpose |
|---|---|
| generate-summary.md | 4-phase process from raw git log to polished summary |
Success Criteria
- Issue number increments correctly from previous report
- Start SHA matches end SHA from previous report
- Commit count and author count are accurate (from raw output)
- Unimportant commits are removed (small fixes, renovate, hydra)
- Related commits are grouped into single paragraphs
- Every paragraph has at least one embedded GitHub commit link
- Links are on the most descriptive phrase, not generic words
- No paragraph starts with a bare link (varied placement)
- ScyllaDB-maintained tool/driver bumps include a brief prose summary of upstream release-note highlights (fetched via
gh release view) — SCT commit is the only link; no cross-repo commit/PR/release links - Opening and closing lines match the template exactly
- Tone matches previous issues — concise, factual, third-person; no author names in prose
- Multi-commit groups link only 1–3 representative commits, not every commit in the group
- Dropped commits listed in a table with SHA, title, and reason for exclusion