motivation

Lots of crucial steps in the SUSE/openSUSE product build workflow are not known or not even accessible by many people but hidden as "custom scripts" on "some machine" in the worst cases. Nowadays infrastructure and build pipelines should be written as code, e.g. in git repos, with UI frontends to show the always current state of what is going on, what needs to be done to release products, where are problems. The least we can do is learn a bit more in this direction.

Currently helpers for maintenance of SLE/openSUSE such as osc omg exist just as git repo, lets have them as packages.

The openSUSE.org official infrastructure is getting bigger and complicateder, so #microservices and #serverless FTW! :smiley: :thumbsup: :icecream:

Glowing Nixie Clock

All our packages have a *.changes file and ideally that file would mention relevant changes from upstream, i.e. during version updates. Currently, we find that information manually when packaging Haskell software. This is unsatisfactory because of the sheer size of the package set and the massive number of updates we receive from Hackage. The packaging itself is completely automatic, but editing the *.changes files is not and this issue prevents us from shipping more packages in Tumbleweed and elsewhere.

In day to day job I often wait for openQA job to change a state. I plan to create chrome plugin which would allow to watch for some certain job and will send you notification when run is end.

I need to get a basic understanding about MD software RAID setup only via command line tools to be able to understand,

Explore the possibility to have a self sufficient frontend server running locally. This server would compile all the frontend code and act as a proxy/middleware pointing either for a dev ref-server or to a local SUMA instance. This way would be possible to do modifications in frontend even without having a SUMA server running locally.

Some ideas from the list:

What is it about?