coordination #93871
open[epic] support process improvement in maintenance requests: packages from different code streams with identical fix sets/features in a single incident
67%
Description
The coordinators changing the process, so the packages hat belong together should be in one incident.
Introduced in S:M:19483:242960
SLE 15 sbd 1.4.1+20200807.883c2f8-3.11.2 -> 1.4.1+20200807.883c2f8-3.14.2
SLE 15 SP1 sbd 1.4.1+20200807.883c2f8-3.9.2 -> 1.4.1+20200807.883c2f8-6.1
SLE 15 SP2 sbd 1.4.1+20200807.883c2f8-3.3.2 -> 1.4.1+20200807.883c2f8-7.1
Updated by okurz over 3 years ago
- Target version set to Ready
thank you. so do you plan to create subtickets for the individual tools that need changing? I think we just have to do it. But having tickets can at least explain to others why we don't do other stuff in the meantime :)
Updated by jbaier_cz over 3 years ago
- Related to action #80690: [qem] Testing of packages in different codestreams but in one incident added
Updated by okurz over 3 years ago
- Tracker changed from action to coordination
- Subject changed from Change in the maintenance requests - improve of the process to submit packages that belong together in one incident. to [epic] Change in the maintenance requests - improve of the process to submit packages that belong together in one incident.
Updated by hrommel1 over 3 years ago
- Subject changed from [epic] Change in the maintenance requests - improve of the process to submit packages that belong together in one incident. to [epic] support process improvement in maintenance requests: packages from different code streams with identical fix sets/features in a single incident
I have updated the title to reflect the driving force behind this change.
The agreement with Maintenance Coordination and Security is that we want to work towards allowing packages from different code streams within a single incident as long as the fix set / features list is identical. Hence the resulting test plan would be very similar.
Apart from adaptions to be done on the tooling side, we might run into situations where we can not finish testing on all affected code streams/products in time. If that happens, the Maintenance Coordination or Security team might decide if to break down the incident into smaller pieces.
Updated by okurz over 3 years ago
- Assignee deleted (
osukup) - Target version changed from Ready to future
We need to clarify what is needed and what can be done without relying on single individuals hence unassigning osukup and moving out of the current backlog