coordination #109349
closed[saga][epic] libreQA and OpenOpenQA: Value through speed, flexibility and security with the community, for our customers
Added by okurz about 2 years ago. Updated about 2 years ago.
0%
Updated by okurz about 2 years ago
- Priority changed from Normal to High
- Target version set to Ready
Updated by okurz about 2 years ago
- Subject changed from [saga] libreQA and OpenOpenQA: Value through speed, flexibility and security with the community, for our customers to [saga][epic] libreQA and OpenOpenQA: Value through speed, flexibility and security with the community, for our customers
- Priority changed from High to Low
- Private changed from Yes to No
Originally I just created this ticket as an April the 1st pun, see the recording of the according workshop session https://youtu.be/uTCNzuq8E3Y . We were surprised that people took it very seriously and even after revealing that this was all a joke they stated that they would still see value in this :) So we can discuss in SUSE QE Tools mob session 2022-04-07 if there is a point to go ahead.
Updated by okurz about 2 years ago
- Status changed from New to Rejected
- Assignee set to okurz
https://progress.opensuse.org/issues/109349
Discussed crazy ideas if the general idea makes sense and what we can learn as individual feature requests from it.
Same as some years ago we can crosscheck our vision regarding "do we build a CI that interfaces with other tools" vs. "we build a test executor that can be integrated into real CIs". We already have isotovideo integrated into CI in some use cases without relying on openQA itself, e.g. the isotovideo GHA job in os-autoinst-distri-opensuse. Also we have the full stack test within the openQA project's CI (circleCI) itself. This one saves for example the log files, the JSON detail files including step details, and the video which is fine to watch. Of course we don't have the nice thumbnails on the job details page.
- Network problems and typing issues: Idea by okurz: Aggressively point out automatically with our tooling when problems happen that are out of our scope, e.g. blame network admins if anything related to network shows up :)
- There is also the opinion that "We are developing fancy features that nobody needs rather than fixing issues where the money is, our tooling for SLE maintenance related tooling". We actually work on improving related tooling continuously but it might not seem as much because the use cases and requirements are so wide spread already. Also we see big benefit in improving underlying tooling (including openQA in this context) to solve the issues for bigger user groups. On top of course there is the high technical debt of qem-bot and qem-dashboard (no/few tests, no architecture diagram, little experience within the team, communication challenges, etc.) so high risk and hence limited motivation.