From 1aeb44139fcc17297b501a1842d47bc30e391e75 Mon Sep 17 00:00:00 2001 From: Christian Ehrhardt Date: Mon, 8 Dec 2025 08:37:51 +0100 Subject: [PATCH 1/3] MIR: clarify that extra tasks go both ways Signed-off-by: Christian Ehrhardt --- docs/MIR/mir-reporters-template.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/docs/MIR/mir-reporters-template.md b/docs/MIR/mir-reporters-template.md index 7a567f63..becfc170 100644 --- a/docs/MIR/mir-reporters-template.md +++ b/docs/MIR/mir-reporters-template.md @@ -47,8 +47,21 @@ 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: please help us to 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 diffeerent, continue +RULE: preparing this new MIR and please reference to the previous MIR. +RULE: This suggestion of per release tasks if 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 you'd more likely add 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 and 20.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 From 93c0d91999f79f47b04b6f65d8aae0a5a8ecaac5 Mon Sep 17 00:00:00 2001 From: Christian Ehrhardt Date: Tue, 9 Dec 2025 16:30:27 +0100 Subject: [PATCH 2/3] dmb: even less misleading cross release rule Signed-off-by: Christian Ehrhardt --- docs/MIR/mir-reporters-template.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/MIR/mir-reporters-template.md b/docs/MIR/mir-reporters-template.md index becfc170..8b4ad5f7 100644 --- a/docs/MIR/mir-reporters-template.md +++ b/docs/MIR/mir-reporters-template.md @@ -45,9 +45,10 @@ 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: please help us to keep the discussion, argument and audit trail together. +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 not, 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 diffeerent, continue RULE: preparing this new MIR and please reference to the previous MIR. From b5eda2db262fac18e5cb36a2f76ba8f1c1e5b8a3 Mon Sep 17 00:00:00 2001 From: Christian Ehrhardt Date: Tue, 9 Dec 2025 17:50:42 +0100 Subject: [PATCH 3/3] dmb: integrate review feedback to sentence structure Signed-off-by: Christian Ehrhardt --- docs/MIR/mir-reporters-template.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/MIR/mir-reporters-template.md b/docs/MIR/mir-reporters-template.md index 8b4ad5f7..efa48418 100644 --- a/docs/MIR/mir-reporters-template.md +++ b/docs/MIR/mir-reporters-template.md @@ -47,21 +47,21 @@ 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 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 not, then please help us to +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 diffeerent, continue +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 if valid in both directions. +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 you'd more likely add to +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 and 20.04. In that +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: 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: #...)