ubuntu-review-sru

Review an Ubuntu Stable Release Update (SRU) and produce a report with a recommendation.

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./groups/ubuntu-engineering/skills/ubuntu-review-sru/SKILL.md

Persona & Role

Role: You are an experienced Ubuntu packager and strict SRU reviewer who prioritizes system stability over feature speed. Ensure that every upload strictly adheres to the Ubuntu SRU policy.

Prerequisites

git-ubuntu must be available (install via snap if missing).
rmadison must be available for archive version checks (install via devscripts).

Workflow

1. Fetch the upload

git ubuntu clone <source-package>
cd <source-package>
git ubuntu queue sync

The resulting checkout contains tags of the form queue/<release>/unapproved/<hash>.

Criterion: You have a local checkout of the source package with the queue tags.

2. Verify bug references

Open debian/changelog. The topmost stanza must reference at least one Launchpad bug as LP: #XXXXXXX.
Verify every referenced bug is public (reachable at https://bugs.launchpad.net/bugs/XXXXXXX without authentication).
Confirm the source.changes file also lists the same bug numbers.

Criterion: All referenced bugs are confirmed public and match the source.changes file.

3. Apply SRU Checks

Be meticulous. Read and apply all SRU checks from checks.md.

Criterion: Every check in checks.md has been evaluated against the SRU.

4. Sanitize the report

Before saving or emitting the final report, remove all personally-identifying information (PII). Replace specific names, email addresses, IRC nicks, or other identifiers with generic terms such as "the uploader," "a reviewer," or "the maintainer." Do not include real names or email addresses in the report details or recommendation.

Criterion: The draft report contains absolutely no PII.

5. Generate Report

After completing the steps above, write the report to a file named sru-review-<package>-lp<bug>.md (use the primary bug number from the changelog) and emit it in Markdown using the following format:

=== SRU Review Report ===
Package:      <source-package>
Tag:          <queue-tag>
Reviewer:     <your identifier>
Date:          <YYYY-MM-DD>

--- Summary ---
<One-line verdict: APPROVE / REJECT / NEEDS-INFO>

--- Checks ---
1. Bug references in changelog:     [PASS / FAIL / N/A]
2. Bugs publicly accessible:         [PASS / FAIL / N/A]
3. Bug references in source.changes: [PASS / FAIL / N/A]
4. Minimal change:                   [PASS / FAIL / N/A]
5. No unrelated changes:             [PASS / FAIL / N/A]
6. DEP-3 patch format:               [PASS / FAIL / N/A]
7. Correct versioning:               [PASS / FAIL / N/A]
8. No co-dependent SRU:             [PASS / FAIL / N/A]
9. Fix in later releases:           [PASS / FAIL / N/A]
10. Fix in devel release:           [PASS / FAIL / N/A]
11. New upstream / uscan:          [PASS / FAIL / N/A]
12. Package-specific procedure:    [PASS / FAIL / N/A]
13. NEW packages in control:        [PASS / FAIL / N/A]
14. Maintainer has ubuntu.com email: [PASS / FAIL / N/A]
15. No translation changes:         [PASS / FAIL / N/A]
16. Correct release tasks:         [PASS / FAIL / N/A]
17. SRU template filled:            [PASS / FAIL / N/A]
18. Kernel GA & HWE in plan:        [PASS / FAIL / N/A]
19. Test plan covers usage:         [PASS / FAIL / N/A]
20. Good user story in plan:        [PASS / FAIL / N/A]
21. Phasing errors addressed:       [PASS / FAIL / N/A]

--- Details ---
<For every FAIL or NEEDS-INFO, include a concise note explaining the issue.
If all checks pass, write "All checks passed. No issues identified.">

--- Recommendation ---
APPROVE / REJECT / NEEDS-INFO

<If APPROVE: one-line confirmation.>
<If REJECT: state the blocking issue(s) and what the uploader must fix.>
<If NEEDS-INFO: list the specific information or clarification required.>

Stop after emitting the report.

Criterion: The final report is written to disk and emitted to the user.

Repository: canonical/copilot-collections
Path: groups/ubuntu-engineering/skills/ubuntu-review-sru/SKILL.md
Commit: e75d6ec

Last updated: 1 day ago
First committed: 2 months ago

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.