Skip to content

MIR: clarify that extra tasks go both ways #349

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
cpaelzer merged 3 commits into from
Dec 16, 2025
+18 −4
Merged

MIR: clarify that extra tasks go both ways #349

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
1aeb441
MIR: clarify that extra tasks go both ways
cpaelzer Dec 8, 2025
93c0d91
dmb: even less misleading cross release rule
cpaelzer Dec 9, 2025
b5eda2d
dmb: integrate review feedback to sentence structure
cpaelzer Dec 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 18 additions & 4 deletions docs/MIR/mir-reporters-template.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,10 +45,24 @@ RULE: address the problem you might spend some time explaining what exists and
RULE: why it isn't a sufficient alternative.
TODO: - There is no other/better way to solve this that is already in main or
TODO: should go universe->main instead of this.
RULE: If the package previously was in main (use rmadison to check),
RULE: and the previous MIR content is still applicable and not ancient,
RULE: just add a new release-task instead of creating a new MIR.
RULE: Otherwise, continue with this MIR and link to the previous MIR.
RULE: If the package is in main in other releases (use rmadison to check),
RULE: and the existing MIR and package content is still applicable and not
RULE: outdated relative to what you want to add, then please help us to
RULE: keep the discussion, argument and audit trail together.
RULE: To do so just add a new per-release tasks instead of creating a new MIR.
RULE: Otherwise - if the existing former case was way too different, continue
RULE: preparing this new MIR and please reference to the previous MIR.
RULE: This suggestion of per release tasks is valid in both directions.
RULE: For example forward when something was MIRed in 24.10 and 25.04 but got
RULE: demoted in 25.10 - and shall come back to 26.04 please add a task to
RULE: the existing MIR instead of creating a new one. Of course the reasons for
RULE: demotion in 25.10 will be important for this case.
RULE: And for example backwards, when something was MIRed for 24.04 onward,
RULE: but later is also needed in older releases like 22.04. In that
RULE: case you likely want to ensure via SRUs that things are up to date anyway
RULE: and yet again - if the content, reasoning and outside factors are not
RULE: vastly different - you'd be expected to add per-release-tasks to the
RULE: existing MIR case which makes it easier for reporter and reviewer alike.
TODO-A: - This is the first time package will be in main
TODO-B: - Package was in main before (Ubuntu aa.bb->xx.yy) (MIR-Bug LP: #...)
RULE: You truly need to understand the difference between main and universe
Expand Down