| name | rsyslog_v8stable_patch_flow |
| description | Handle rsyslog post-.0 v8-stable updates, including patch-release ChangeLog sections, PRs targeting v8-stable, preserving stable merge commit hashes, and merging v8-stable back into main cleanly. |
rsyslog_v8stable_patch_flow
Use this skill when a change belongs to v8-stable after an .0 release has
already shipped, especially for follow-up fixes such as 8.2604.1,
8.2604.2, and later patch releases. Pair it with rsyslog_changelog,
rsyslog_commit, and rsyslog_pr_babysitting as needed.
Core Rule
Do not rewrite a released .0 ChangeLog entry to describe later patch-release
behavior. Keep the .0 entry historically accurate, and add the real
follow-up delta to the appropriate .1, .2, etc. release section.
If a patch fix reverses, narrows, or corrects behavior that was documented for
.0, keep both stories:
- the
.0 entry describes what the .0 release did;
- the patch entry describes what changed after
.0;
- issue links stay with the release entry that actually resolved that issue.
Stable Worktree
-
Fetch current upstream branches:
git fetch upstream main v8-stable --prune
-
Create or reuse a sibling worktree from upstream/v8-stable, not from
main, for the stable follow-up:
git worktree add -b codex/<topic> ../rsyslog-<topic> upstream/v8-stable
-
Target the PR at rsyslog/rsyslog:v8-stable. Do not open these patch
follow-up PRs against main unless the user explicitly asks for a main-only
change.
ChangeLog Patch Sections
For post-.0 stable work, add a patch-release header near the top of
ChangeLog if it does not already exist:
--------------------------------------------------------------------------------------
Scheduled Release 8.yymm.N (aka YYYY.MM) YYYY-MM-DD
Use N=1 for the first post-.0 patch, then N=2, and so on. Keep the
aka YYYY.MM value tied to the original .0 monthly release. Insert entries
for the patch section in the normal rsyslog format:
- YYYY-MM-DD: component: concise change summary
Operationally useful explanation of the behavior and impact.
Closes https://github.com/rsyslog/rsyslog/issues/NNNN
When moving a follow-up note out of a later or wrong release block, restore the
old block to the wording that matched its original release, then add the
follow-up entry under the patch header.
PR And Validation
- Keep PRs draft by default unless the user asks otherwise.
- Use the usual rsyslog metadata: assign
rgerhards, set the active release
milestone, and choose the best-fit category label.
- For ChangeLog-only fixes,
git diff --check plus rereading the edited
release blocks is normally sufficient. State that no build or container
validation was run because the change is text-only.
- For code, tests, build logic, or workflow changes, follow the normal
rsyslog build/test/container validation skills.
After The v8-stable PR Merges
After the stable PR is merged, make main contain the exact stable history
instead of cherry-picking or recreating it:
-
Fetch both branches fresh.
-
Fast-forward local main to upstream/main.
-
Merge upstream/v8-stable into main with a normal merge commit, using
--no-ff so the stable merge commit remains reachable even if a
fast-forward would otherwise be possible.
-
Resolve only expected conflicts. If the user says current main wins for
a file, use git checkout --ours <file> and stage that file.
-
Verify:
git merge-base --is-ancestor upstream/v8-stable main
git status --short --branch
-
Push main to upstream if direct push is permitted.
If upstream/main is protected, push the merged branch to the fork and
open a PR targeting rsyslog/rsyslog:main.
Finally, sync the fork's main if local workflow instructions require it.
This keeps the merge commit from the stable PR reachable from main, so future
v8-stable to main merges stay clean and retain the stable-side commit IDs.
