We all pant for customer data. Which hardware do customers run ? Which packages are installed ? Which services are running ? etc. pp. A lot of this data is in the supportconfig. But this is neither collected, nor centralized, not easily accessible.

There is a running gag built into openQA called interactive mode. It goes like this: "if you need the interactive mode, it's broken". The reason: the so called interactive mode is a collection of hacks - in theory making it possible to update needles in a running test. But in fact it's a UI desaster that almost never works. So the goal of this hackweek project is to get rid of it - and instead build a real control from the webui into the backend allowing tests to be written on the fly including needle creation/updates. Easy as that.

The openSUSE build service could build hundreds of packages in parallel but in practice serial package dependencies prevent that.

L3 bug reproduction often requires becoming the admin for a moment. I'd like to write down some nifty tricks I used to get certain “interesting” system configurations to work.

I've attempted this several times already and each attempt had different shortcomings. I'm kind of curious about how exactly will I fail this time. And it looks like I haven't failed this time.

Automate the process described here: - https://github.com/aspiers/git-deps/#use-case-2-splitting-a-patch-series

Live audio tools could use some work in openSUSE and are fun to play with. Finally many of these tools are making it into tumbleweed (And Leap 15.3) especially Cadence.

I have several themes in progress, they all need lots of work before they could be used with openSUSE. * The gtk people keep changing things so the gtk theme I use to match my enlightenment theme also needs fixing.