coordination #93871
open
[epic] support process improvement in maintenance requests: packages from different code streams with identical fix sets/features in a single incident
Added by jkohoutek almost 3 years ago.
Updated almost 3 years ago.
Estimated time:
(Total: 0.00 h)
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
- 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 :)
- Related to action #80690: [qem] Testing of packages in different codestreams but in one incident added
- 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.
- 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.
- 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
Also available in: Atom
PDF