ancorgs

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.

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.

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.

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.

YaST code organization is a mess at many levels (files location, namespaces, code dependencies...). Recently we created this gist to put some of the issues on the table

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 goal of this project is to write a proof of concept of a new philosophy for yast2-storage-ng. Instead of just extending the API offered by libstorage-ng, the idea is wrap libstorage-ng so the Ruby code using yast2-storage-ng does not have direct visibility (unless explicitly desired) on the libstorage-ng classes and methods.

This project is about fixing this known Jangouts issue that is reported over and over, since many user experiencing problem with the outgoing WebRTC traffic or with camera authorization can "lurk" what happens in the room without being noticed.

In a quite natural and steady way, all my relatives (wife, kids, mother, aunt...) have adopted openSUSE in their computers. There is only one resistance spot. My father's computer (HP+Windows8) implements all kind of mechanisms to avoid dual boot.

Time for technical housekeeping in the shared Gran Canaria office.

The theory behind the partitioning proposal of yast2-storage-ng is that all possible distributions of partitions in the disk are evaluated and the best one, according to this criteria, is chosen. But I have found several examples in which is hard believe that the result is actually the optimal distribution of partitions.

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:

We got a couple of GSoC projects around Jangouts this year:

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:

Description

Description