To follow a responsible disclosure while dealing with security issues on Open Build Service, we are going to setup a gitlab project mirroring our github project and set CI, using gitlab CI, to make sure that the security changes aren't introducing any regression and avoid embargoed issues being leaked.

I'd like to spent some time improving the network for our office in Gran Canaria in the following aspects:

"salt-toaster" allows you to test multiple Salt package flavors across different operating systems via Docker containers. This project is heavily used on the SUSE Manager team to hardening the Salt package that is shipped on the openSUSE/SLE distributions. Link to GitHub repository

zypp-closure is a small helper tool making use of libzypp and the metadata of product repositories.

When we started brain storming a project for hack week, one of the floated ideas was to remake the 1983 film WarGames, and for lack of available space, a local lot with storage units was proposed. Over the course of the following years, while we planned, we realized that this whole idea would not be the most feasible, but it still felt like we were onto something.

Currently, each filesystem developer does his fstests runs (a testsuite for regression-testing of filesystems) on his dedicated test machine, on Orthos machine, ... This not only means duplication of efforts to automate this testing but also leads to inefficient use of resources (sometimes the test machine is just idle, sometimes you would need more tests to run in parallel to speed up development). The goal of this effort is to use SUSE Engineering Cloud to implement fire-and-forget fstests runs where you specify kernel to test (fetched from git tree or so), fstests configs to run, and then just pick up test results later on...

The purpose of this project is to train myself in SUSE Manager and SaltStack.