The Problem: many bugs filed for openSUSE go to the screening-team by default and often remain there for weeks, so that developers (who would be interested in analyzing or fixing these bugs) do not learn about them. However, the screening process is a hard one

Those working remotely or managing a distributed team know it: face time is invaluable. The former openSUSE team has been using http://sqwiggle.com to keep in touch and Google hangout to hold a stand up meeting every morning.

Once again, the SUSE band is coming together to make music and we're planning a party this time round!!!

Investigate the good way to put sikuli into openqa.

We have some internal systems for videoconferencing like Big Blue Button or OpenMeetings. But in my experience none of them can compare to Google Hangouts, which is still the best free (as in free beer) alternative for videoconferencing with integrated screen sharing.

A new Puppet Master will be set up for the openSUSE and public SUSE infrastructure. We will need to move the puppet code from the old server to a new Gitlab instance, deploy it to the new box with r10k, and perform syntax, validation and RSpec testing through ci.opensuse.org

During the last CSM workshop we identified the need to have a good way to share the images we use for testing. We have documented the requirements and the current status in this wiki page (we even have a diagram).

Working remotely has many advantages, but you sometimes lack some infrastructure. Specially if you use several computers or you share space with other SUSE co-workers. We are 3 Susers in Gran Canaria and we plan to share an office. So we have bought a Cubietruck, a tiny device with minimum power consumption, an ARM processor, a SATA interface and a Gigabit ethernet.

The goal of openQA is "test as a QA engineer". But openQA has no ears - all we can test for are DTMF sounds. And even those are very bad.

We are right now testing a patch to Janus that will hopefully give us the stability we were missing in http://jangouts.suse.de. As a consequence, it's reasonable to expect a wider usage of Jangouts inside the company. Thus, I want to share maintainership of Jangouts as much as possible. The more developers know how to fix errors and implement features, the better.

Right now, every time a new team wants a new room in our Jangouts instance, they have to ping me and I have to manually create the room. That means:

The current Jangouts UI is limiting us when thinking about adding new features. Some examples:

The idea is about an easy way to allow users to make upgrades (e.g.: changing from one major version like 15.0 to version 15.1) using a GUI and as easy as they can in Ubuntu.

I'm using Conversations (XMPP+OMEMO) as an encrypted IM solution. Since a lot of groups organizing them self using WhatsApp, it's hard to stay away from it.

After an internal call for help to take over software.opensuse.org deployment, I spend some time studying the code in order to find out what would it mean to take it over.

Quite a big part of openQA is testing the installation of SUSE products. All of them are installed by YaST. So a big quantity of problems found during openQA testruns are YaST problems.

Hackweek 18 Update

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.

Motivation / Problem

The idea is to create a bootable medium (eg. pendrive) that allows:

Yes this project is yet another project for creating a Suse Manager clone.

YaST dumps quite information to its own log file (placed at /var/log/YaST2/y2log). That info is very useful to understand and discover what is happening when an issue appears. All YaST modules write into this log file, and the brand new yast2-storage-ng is not an exception. Some improvements are necessary regarding to the logging of this new module:

Let's use the Hackweek to improve Ruby, the programming language I use every day. It is while using a language when you can realised that things that need/can to be improved, so there are many things that only Ruby developers can raise up. Also, getting involved in the development of Ruby will help to get a better understanding of how it works. So I will take my ideas/concerns to the Ruby community and implement some of the them in the code of the Ruby core.

A good way of getting to know a new programming language is... writing some code. So although there are some good IRC bouncers, like ZNC, we want to write another one just for learning.

Make a final attempt to implement a graphical user interface for grub2 (gfxboot2).

Motivation: "Make Jangouts Great Again!!"

Mozilla's DeepSpeech project[1] is using TensorFlow and some paper from Baidu to make an open source speech to text system, based on deep learning (TensorFlow). The current project allow the training for own local datasets, but also there is a pre-trained model that can be used during the development.

Idea is create applet with same functionality which provided by network-manager applet . Gather more detailed requirements is part of fun :)

Right now, during the (open)SUSE installation process, the changes to be performed on the storage devices are presented as a list of actions such as:

As we have grown in our remote and non official office at Gran Canaria we had to rent another space. This new office is almost empty and we need a little bit of love to improve the sensation of relax and commodity while we do what we love most.

Sorbet is a gradual type checker for Ruby.

We already tried to improve the Jangouts data model in the past and, although we made quite some progress, we did not finish it. I've been playing a bit with React and Redux lately, and I would like now to try a different approach replacing Angular with that combo. Using Vue.js might be another option too.

Project Description

Project Description

Project Description

Project Description

Initially, the Agama D-Bus service was written 100% in Ruby. For many things, it relies on YaST, so it makes sense to use the same language. It was great to have something working quickly, but it also had some drawbacks. The main problem is that, as YaST is not thread-safe, we separated the service into different processes (storage, software, localization, etc.). The system became most responsive but at the cost of eating a lot of RAM.

Description

TUIs (Textual User Interface) are a big classic of our daily workflow.

Description

There is a character limit of <=80 characters in s390x, for OSD we workaround this problem using a url shortener, like http://s.qa.suse.de/ but we don't have anything equivalent for O3. Some colleagues recommended https://v.gd/ but some initial test showed that cannot shorten ftp urls.

Description

Description

Description