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
www.opensuse.org is the single most accessed page in the SUSE/openSUSE universe. With 1.5 million visits per month it generates 2.5 million page views and has around 500 people on the page at any given time. Yet it's one of the oldest, crufty pages we have!
It doesn't concentrate on what it should do: Tell people about the distro so they download it. It's design is 5 years old, it's not mobile, it's not accessible. There is absolutely no interactive, engaging content at all and the technology used goes as far as a shell script/cron to update dynamic content.
Twopence is (will be) a remote execution engine for tests, able to run tests in virtual machines and real hardware through various means of communication : virtio for KVM / QEmu, ssh on top of libssh, serial lines. This library can be called from shell and ruby wrappers.
While it is already functional (and used), it still needs polishing, stabilizing, and extending. It is also planned to integrate it with Pennyworth (project Machinery) and let it go fully Open Source.
It's 1.5yrs since we've launched the last Studio version. Customers are asking about a roadmap, a new version...
After discussions with AJ, Adrian, Alex, I want to create a draft plan/concept how such a Studio successor could look like.
I would like to learn Salt by converting ansible scripts to salt states.
Current ansible scripts do some QA tasks on cloud nodes, so i thought it would be a good idea to convert them to salt after reading salt tutorial.
In the YaST installer, make disk encryption method, mode, key strength, random source etc configurable.
The rationale is that user requirements may differ, and we would like to offer some advanced options instead of changing defaults.
openSUSE Connect is almost forgotten tool used only for elections. It would be nice to update it, polish it a little bit, disable functions that nobody uses and fix those few that people would actually like to use.
Implement file system image build using the Builder infrastructure. The project will create additional builders for the ext filesystems laying the ground work for restructuring other filesystem builders.
Occasionally, new versions of openQA break things. How do you stop that? MORE TESTING!
Testing openQA by using openQA to ensure the new versions don't break should be a good example of how openQA can test everything and anything, even itself.
My home server, and my other box hosting https://sysrich.co.uk are both in need of a bit of a refresh
While I could be nice and conservative and pick an openSUSE regular release, I'm actually considering using openSUSE Tumbleweed, and fully embracing the 'Servers as Cattle' concept
<p>There are numerous testing tools for the GFX stack available - the oldes being the xtest suite. At the same time, we are still lacking automated test environments for the funktionalities of DRM, Mesa and X. Ideally the tests should be performed automatically and unattended and the results should be compared to previous runs to detect regressions.</p>
<p>Research what tools exist to date and how they can be employed.</p>
Our beloved competitor developed and use project-wide message bus called Fedora Infrastructure Message Bus. This project was already adapted, or is being adapted, also by Debian community.
During Lucky Thirteen I want to get deeply familiar with the concept and implementation, deploy test scenario and write plugins for OBS and openQA to talk to each other.
For our daily work, usually we need to check running result from openQA as a good reference for the quality of a specific build. I'd like to take this chance to make openQA deployed and try to review the test scripts.
To say it's a review, it's better to say it's a good way to learn from others. I'll review test scripts in openQA project as much as I can, digest them and learn how to write Perl script more pretty. I'll make some notes for sharing.
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.
So my hackweek project is to do research on how to do proper sound verification. The keys are proper normalization of the volume and the sample rate.
jenkins is a great CI system (continuous integration) with a plethora of plugins available. SUSE QA uses openQA extensively as it excels in distribution and product testing - not only image comparison (common misconception ;-) ). How about combining both in using jenkins with plugins to act as a UI for openQA?
Right now internal SLE development is still organised & structured around the concept of 'Milestones'. Schedules are defined, deadlines are set, and off we go making Alpha 1, 2, 3, Betas 1, 2, 3, RC's, and so on.
Meanwhile, QA has evolved, and with openQA and other automated tooling we are increasingly testing SLE in a more agile, rolling model, testing every single build as soon as it's produced by OBS, and just paying extra attention to the Milestones with additional manual testing.
To make sure openSUSE can coexist nicely with an existing Windows installation, we need to have automated regression testing. UEFI and secure boot are especially interesting.That means installing Windows and openSUSE in parallel in openQA.
Instead of just uploading some prepared hard disk image, openQA should ideally install Windows itself and save the generated image. In a second run openQA can then install the latest Leap or TW on that disk image.
openQA has a well earned reputation as a 'full system' testing tool, able to test a system end-to-end from the operating system to it's applications on a number of different platforms and architectures, including VM's & Bare Metal.
But one area of weakness is it's usefulness as a testing tool for developers or packagers. openQA can easily test a package once it's INSIDE a distribution, but how do you test that package BEFORE submitting it to the distribution?
currently when you navigate to Test Results page - it will load everything before show you the page. I plan to change this model into "load on demand" approach
Test Details page currently show you thumbnails for all modules. Want to add expand/collapse functionality for thumbnails - by default you will not see them for passed modules. But you will have ability to expand them. Also I will add "Expand All"/"Collapse All"
The Kubic Project currently produces a "CaaSP-like" Tumbleweed OS, focused on Kubernetes clusters
However many of the attributes of Kubic (read-only filesystem, transactional updates, containerised services) could be an interesting platform for another use A Chromebook-like Linux Desktop
Few months ago I switched my home workstation and media center to Micro OS desktop and I cannot imagine switching back to normal distribution.
After some consideration I realized it should work fine (even better) on the notebook I am using for work.