QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

Motivation¶

Document how we are going to follow the openQA Maintenance agreement in YaST squad:
https://confluence.suse.com/pages/viewpage.action?spaceKey=qasle&title=openQA+QE+Maintenance+Review

Acceptance criteria¶

AC1: Document the process to be followed by reviewer, for example in confluence.

Suggestions¶

This is the draft shared initially with all team members:

@qe-yast basically will have this 2-step approach in our team to review the maintenance updates:
Reviewer will identify if it is an update issue.
 - if it is an update issue, go the #team-lsg-qe-openqa-review and communicate it.
 - if it is not, use label to force the state to soft-failed (notice that is only valid for one day, next build doesn't carry over that override) pointing to corresponding bug/progress ticket. 

we have 24 hours for doing the above, counting since openQA shows the failures. After that 'reaction' period (or even better if we can do it earlier, but it is not the main goal) the reviewer will:
 - Move to Development group (fully or partially, trying to not loose too much coverage) the product/tests failures unrelated with updates. The reviewer will add in the comment of those jobs with overwritten failures the PRs/MRs needed. From than point we can take our time to fix it properly there and everything is tracked.

We should not forget forget to label each of the problem in subsequent runs in the development group.
The process to move back configuration from Development group to official group will be done by PO/SMs, it is not as simple as revert, as some issues will be fixed soon and other will remain perhaps forever broken. We can exclude that part from documentation for now.