Disclaimer: I have zero knowledge on security studies and very little knowledge on our internal security workflow. The idea popped out from the observation on my daily work which includes backporting security fixes, occasionally a couple of which are embargoed. Lashes are welcome if you find the idea stupid. When an embargoed vulnerability reaches SUSE, the related bugs / fixes are usually only exposed to a small group of people including maintainers of the affected package. While bugzilla can made an issue private for that purpose, For OBS I'm unaware of an option like "private project / package" that blocks unwanted access (please correct me if it does exist).

Get involved in the development of gnome-shell in this week. backlog:

There are some multiqueue I/O scheduler nowadays, such as bfq and kyber. And bfq is really complex (about 10K LOC)and error prone from my understanding, since kyber only has less than 1k LOC, it should be more easier and practical to read/play it in one week.

GitLab offer the possibility to use the CI on Kubernetes. We could then offer varios R&D teams the possiblity to use the GitLab-CI with "free" resources for testing on GitLab-Ci.

The project to give an investigation of the difference between openSUSE Leap (aligned with SLE), Tumbleweed (SLE's future release) and Fedora (a good gnome based Desktop outside SUSE release family), trying to have a better understanding of what the Leap/SLE desktop can possibly be as a general platform in future releases. The investigation will focus on gnome-software update stack, initial setup of the system after installation, as well as the CJK support. Surprising difference is not excluded during playing across distributions.