Last week, the first beta of Applications and Platform 4.13 was released. This week, beta 2 is coming. The openSUSE team has already asked its users to start the testing engines and that request extends to the entire community of KDE users!
What's to be tested?
Let's go over a list of major and minor changes in this release, and areas where developers have explicitly asked us for help.
A major new improvement is the introduction of KDE’s next generation Semantic Search. This makes search faster, saves memory, improves stability, and generates more reliable search results. And it could use a good testing.
Various applications use the search abilities, most notably Dolphin and KDE PIM (see the next section). Also tagging (Gwenview!) and KRunner (Alt-F2 run command dialog) can use some attention.
Some of your existing data will need to be migrated from the current Nepomuk backend to the new 'Baloo' backend. Running the nepomukbaloomigrator should take care of that. The old Nepomuk support is considered “legacy” (but it is still provided). The programs that have not yet been ported to the new architecture have Nepomuk integration disabled. One significant regression is file-activity linking, which will not work until KDE Applications and Platform 4.14. If you rely on this feature, we recommend not upgrading at this time. For the final release, distributions might choose to optionally have the old search (Nepomuk) available.
The Kontact Suite (email, calendaring, contacts and more) benefits from the improvements in search; there is also a new quick filter bar and search. IMAP will be more reliable, and performance should be massively improved. There is also a brand new sieve editor and integration with cloud storage functions, where Kontact can automatically put big attachments on Box/DropBox/Hubic/Kolab/ownCloud/UbuntuOne/WebDav/YousendIt and link to them.
Okular, Kate and Umbrello
Document viewer Okular has a lot of new features like tabs, media handling and a magnifier, improved Find and Undo/Redo.
Text editor Kate has gotten a lot of attention, so there are many new features in the areas of further VIM style support, bracket matching, highlighting and more. You can read the blogs on the Kate site and test some of that awesome.
The UML modeling application Umbrello received some improvements and bugfixes. If you use it, now is a good time to help out a little and see if it works better! There is new duplication of diagrams and improvements to the context menus (which only shows relevant actions).
Education and Games
We received a special request from developer Ian Wadham:
Please give the new version of Palapeli jigsaw puzzling a whirl. This contribution to KDE is my celebration of 50 years as a programmer. I started in April 1964.
If you ever enjoyed jigsaw puzzles, especially those 500 and 1,000 piece boxed puzzles, please take a look at the new version of Palapeli. The main thing is its attempt to make solving large puzzles (300 to 10,000 pieces) possible, realistic and enjoyable on a small screen. You can make your own large puzzle from any photo or picture file you fancy.
So I am very interested in *usability* feedback (look and feel). As well as bugs, of course. I am currently "testing" on a 10,000 piece puzzle ... The Handbook changes should be finished in a few days, but there is already a long help message that appears when you start a large puzzle (> 300 pieces).
The new features are described, but in a technical way, in the usual place.
Have fun, everyone.
Artikulate (technical information) is a brand new application in KDE Edu and will have its first official release with KDE Applications 4.13. Find some information about it on community.kde.org.
And how does that work?
Testing follows these steps:
- set up your testing environment
- pick something to test
- test it
- back to 2 until something unexpected/bad happens
- check if what you found is really a bug
- file the bug
You're not alone!
In KDE, testing is not only an individual action by our users but it's also coordinated through the KDE Quality team. That does not mean you must work or coordinate with them, but it sure helps! You can reach them on IRC, as well as on their mailing list.
The testing of this beta is also coordinated on this forum page for those more comfortable on forums.
The KDE Quality Team wiki page is worth a read if you're unexperienced. There is even a real tutorial on becoming a KDE tester!
Get the beta and prepare
To get testing, you can either build the source of the Beta or RC, or grab packages for your distribution. If your distro is not on that list but you know there are packages, you can add them there!
The second step is to create a testing user account. We recommend this to prevent destroying data on your current account. Many users also use a separate installation of KDE software on a separate partition.
On most flavors of Linux, creating a new user is easy. On the command line, it goes a bit like this (as root):
- useradd -m kde-test
- passwd kde-test
And now you've created a user kde-test and given the account a password. Just switch user accounts (menu - leave - switch user or Alt-F2 - switch) and have fun testing!
The real testing
Testing is a matter of trying out some scenarios you decide to test, for example, pairing your Android phone to your computer with KDE Connect. If it works – awesome, move on. If it doesn't, find out as much as you can about why it doesn't and use that for a bug report.
This is the stage where you should see if your issue is already reported by checking on the forum, IRC channel or mailing list. It might even be fixed, sometimes! It can also be fruitful to contact the developers on the relevant mailing list.
Finally, if the issue you bump into is a clear bug and the developers are not aware of it, file it on bugs.kde.org.
How else can I help?
Another useful contribution is triaging bugs:
- determine if it's really a bug (it can be reproduced)
- find out which component has the bug and
- assign or cc the maintainer of that component
If you can’t reproduce a bug, the bug might have to be marked as “WORKSFORME” or “NEEDINFO” if you can’t reproduce it due to a lack of information. And in some cases, the bug report is plain wrong (“Plasma doesn’t make coffee“) and must be closed as “INVALID”. You can find more information in the Ultimate Bug Triaging Guide. As long as you can't close bugs on bugzilla, you can just add your information as comments and they will be picked up by a maintainer – it is just as useful!
It is a big help!
We're very grateful for your help in this. Not all areas of our many applications receive the same amount of care and attention, and there may not always be an immediate reply to bug reports. However, developers greatly appreciate the attention given to their applications by users and testers.