The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.
EGI DMSU Ticket Followup
| Technology | Software Component Delivery | Software Provisioning | UMD Middleware | Cloud Middleware Distribution | Containers Distribution | Technology Glossary |
| DMSU | | Interactions | | Ticket priorities | | Ticked followup | | Documentation | | Internals | | Glossary |
Besides handling the incoming tickets DMSU also performs elementary followup of the tickets assigned to the 3rd line. This work is restricted (due to limited available effort) to checking high priority categories, and to basic aggregate checks on others.
Approach to the ticket is differentiated according to their priority:
Top Priority and Very Urgent
Experience shows that these priority levels are very rare, top priority occurs only once per several months, and there are only upto few dozens very urgent ones per year. Therefore it is feasible to give special care to these tickets, including manual one-by-one followup.
When such ticket is assigned to 3rd line, the TP is obliged, withing the reaction time given by SLA, to assign ETA to the ticket. Assignment of ETA is essential for EGI Operation to plan accordingly (e.g. whether to deploy emergency workarounds).
The assignment of ETA is checked by DMSU.
When the ETA time arrives, DMSU checks whether the fix was delivered. If not, TP is requested to provide a new estimate and an appropriate justification. If there are doubts, the tickets can be escalated to TCB.
Urgent and Less Urgent
The process described bellow is tentative, and further discussion is required.
On the contrary, there are typically 200 tickets of these priorities handled by DMSU every quarter. These numbers make any one-by-one followup in a centralized way not reasonable.
It's agreed that solving all submitted tickets may also reach beyond the capabilities of TP. Therefore the Fedora approach of closing low-priority tickets on major release, regardless of the fix availability, is taken. This is a tradeoff approach, avoiding the ever-increasing backlog of tickets. If the reported problems persist in the new release, and users are still affected, they are expected to submit new tickets.
More specifically, the following is expected from TP (assuming the major release at month X):
- When a fix is available in a revision or minor release, the ticket is closed as solved.
- Before a major release, e.g. at month X-1, the TP is expected to run a pre-release campaign on all open tickets.
- Issues that can be solved with feasible effort are fixed in this campaign and the fixes are scheduled for the upcoming major release.
- All issues submitted earlier than month X-1 are closed as unsolved once the release is available.
This round should happen for major releases, and it is optional for minor ones. We also require that it is done at least once per year if major releases are less frequent. As long as the process is followed, every major release is started with a clean table.
Finally, DMSU checks, at time point X+delta, i.e. well after the release, that there are no open tickets submitted before X-1.