I want to understand the basics and architecture of KMS / DRM drivers in the kernel (also in mesa, but this project is more about the kernel-side). I will read docs and attempt to implement a virtual kernel-mode-setting driver (vkms) as described in Documentation/gpu/todo. This would be a KMS driver for a fake modesetting graphics device, just using normal system memory. This can be useful for learning, but judging from dri-developer discussions, also useful for testing hotplug races, plane blending and finding other KMS/DRI infrastructure bugs. Some items to implement:

SUSE has lots of information in a jungle of tools within the company network. We want to create a platform to extract and refine (distil) the available information and display it in a meaningful manner. The overarching goal is to make available data more accessible. The initial idea sparked in a Knowledge management workshop for the SUSE Documentation Team. A first, refined version was presented as OpenDoc at openSUSE Conference 2016

Github Project

The Challenge

Plans of the Project

After some time I would like to move KF5 translation ahead again.

make crowbar+openstack work on openSUSE Leap 42.2 part of this is setting up public CI. For that, we need to port mkcloud to work on Debian.

djmount is a neat idea - see UPnP/AV resources in your directly in the file system. Unfortunately the code hasn't been maintained for ~10y, and - at least for me - seems to by plagued by various bugs causing crashes and what not. There's currently no official openSUSE package. This project aims to pick up the code, fix bugs, and make the tool actually useful again. The code itself seems to be in quite a good shape, so this should be doable.

It looks like OTR will never be implemented for Empathy. But two years after Snowden end-to-end encryption is really a basic requirement for every secure chat program. A few weeks ago I read about a promising protocol called OMEMO which seems to overcome all shortcomings of OTR and GnuPG with respect to instant messaging. This would be a option for Empathy to finally support end-to-end encryption.

DevOps is hot, and SUSE now is changing that we will not only provide OS and relative products but also online-application-like products e.g. docker application, so L3 service needs to improve as well.
Google has established their DevOps implementation - SRE system, and has maintained long time, I opened this project for researching if DevOps way could be applied on L3 service referring to Google's experience.