We are pleased to announce our openSUSE Weekly News Issue 199.
Archive for 2011
This years openSUSE Election Committee is in the pleasant position to announce the 2011 Board Elections.
So, if you want to participate in the openSUSE board and influence the future direction of the project please stand up and announce your candidacy. If you want to vote for the candidates, please make sure your openSUSE membership is approved. If you are a contributor of openSUSE but you are not a member yet, apply for membership now and be a part of the changes to come.
|November 2, 2011|
|November 9, 2011|
Let’s meet on IRC freenode channel #opensuse-marketing and discuss the Launch and pre-launch activities to promote openSUSE 12.1
Friday 16.09, while working on the openSUSE 12.1 marketing actions during the Marketing Hackfest, two of us had the spontaneous idea to suggest an interview to Michael Miller(Vice President of Global Alliances & Marketing for SUSE), asking him a few questions we could have in the openSUSE community. We did not have the time to go around, to find the FAQ or to choose the “best questions”. It was kind of “shall we do that, around a cup of coffee ? Why not ?”. And Michael Miller accepted our proposition, without any objection or any “joker’s need”.
One of the most important activities during software development is testing. In FOSS community, software often gets tested by the developers themselves, other developers and volunteers. During the openSUSE 12.1 development process it has been important to keep Factory working properly. Testing this is however a rather boring, repetitive task: the tester has to boot up a Factory ISO as often as possible and check if the basic applications start up and work. We don’t like boring tasks so the openSUSE Project has been using the automated testing framework openQA to test this release daily!
This article explains how openQA works and how you can help keep Factory working! We’ll also give some links to more information about testing to help new testers learn the trade but also give experienced testers some new tips and insights!
Testing is generally done on the latest development release, with additional testing sometimes done using updates from Factory to verify bug fixes. Everything in Factory is passed through our automated test framework openQA. You can read more about openQA an the announcement openSUSE News. openQA is a great test suite and is capable of producing videos of the whole process and also screenshots. This greatly reduces the overhead for the testers. An overview of the test results can be found here.
openQA can be used both for bug reporting and bug triaging. To find and report bugs using openQA just visit the openQA test result page, browse through the web interface and look for failed tests. Click on the corresponding tests, to view the results. If your copy of openSUSE is different from the version that has been tested at openqa but you want to/need to do additional testing, fire up your vm and install the version openQA used (or a newer one). You can check for bugs in the tests that have not been autochecked and also look for hardware related (note that in this case you will need to install it on your system instead of a vm) and other possible bugs that openQA might have missed. If you find a bug, report the bug to our testing team or file the bug yourself. Be sure to make good use of the openSUSE Testing documentation at the Testing portal, the Bug report how-to and read the Bug Reporting F.A.Q!
Bernhard, the author of openQA has come out with a nice web interface for bug triagers to make them easier to browse through bugs. The web interface provides with a list of some random bugs. If you are interested ino a scpecific component, then you can use the search bar and look for them. Once you have a random list of bugs that may interest you, you mark a bug as taken. This will reserve the bug. Now fix the bug and update the bugzilla accordingly to get more info or mark it as fixed. While the real triaging is still left for the developers to do, the web interface makes it easierfor them to find bugs..
Adding tests to openQA
An important part of openQA are of course the tests themselves. The more tests are written the more openQA can cover. Tweaking preexisting tests or creating new tests is not very difficult. You can get the sources of openQa from gitorious. You will need it to have the examples and tools needed to build new test cases. Once you have the source, you can find the test modules spread across os-autoinst directory. Every test module has two parts, one which contains the general flow of sendkey events to test an application or feature, the second one being a set of md5 hash sums to determine the validity of test results. os-autoinst/bmqemu.pm can act as a reference for the functions that can be used in our test modules. The commands can be used to write the desired test module. To verify if the test results are valid or not, a set of md5 hash sums of screenshots of the desired results is checked. To calculate these hashsums you can use tools/inststagedetect2.pl. The following article provides an indepth howto on writing a test module in openQA.
If you need help/support in testing, if you have topics to discuss or if you are just interested in this area, join the email@example.com mailing list (see openSUSE:Mailing lists page how to subscribe). Have a look at the Testing portal or directly contact our core testing team
At the openSUSE conference 2011, there was especially one area that caused us the previous years some trouble and this year nobody spoke about since it just worked fine: Wireless internet access.
So, what have we done right this year? It was basically wiring internet ourselves to the location and setting up the wifi controllers sponsored by Aeroaccess.
The next release of openSUSE is expected to bring a large number of improvements and changes. Many of these are the ‘usual’ updates any Linux distribution offers. These include the latest Firefox, GNOME 3.2 and KDE’s Plasma Workspace 4.7. Under the hood, we have Linux kernel 3.1 and we expect to be the first to ship Google’s new programming language Go. We also overhauled our boot procedure introducing systemd and Grub2 (testing!) and of course we’ll ship the latest developer tools and libraries as well as all the sysadmin goodies openSUSE is known for!
But we also have some really unique treats. The coolest among those is Snapper, a btrfs-based tool which allows you to view the differences between current and previous versions of files on your system and lets you roll back the changes, bringing back lost files or undoing damaging overwrites.
The changes in underlying boot technology, the new tools like Snapper as well as the rest of the operating system need a good workout for the release! So now we need YOUR help! Go to the download page and grab your copy of openSUSE 12.1 RC1 and test it on your desktop, in a VM or on a laptop!
You can find information on testing on the openSUSE Testing wiki page which also includes a link to the most annoying 12.1 bugs. Help us shorten that list by re-testing the problematic areas or by fixing the bugs; or help us find new pressing issues!
Get openSUSE 12.1 RC1 from this page.
More information and other helping-out
The openSUSE 12.1 Portal page has been set up but still needs quite some work. There are screenshots to be taken, release notes to be written and Documentation to be composed. We also welcome help with translation!