KDE Testing for 4.10 – The Developer Version

The KDE Quality Team is designed to, amongst other things, manage the release tesing for KDE and move towards having a structured approach rather than just releasing some code, and seeing what happens.

This means keeping clear instructions on how to install the latest betas, promoting testing and trying to do the testing more effectively.

What's being done

  • Making easy instructions on how to get the latest release
  • Making and running "release checklists" for various components of KDE to ensure everything still works as it should
  • Making a list of changed areas, and putting an emphasis on testing these
  • Running bug days, with bug reporting tutorials to improve the usefulness of the bug reports

As a developer how can I help/benefit from this?

If you have refactored a large area of code, or introduced a new feature, please add it to the to-test list (http://community.kde.org/Getinvolved/Quality/Beta/4.10/AreasToTest) along with instructions of how to get to test it. Use end-user terminology, and keep things deliberately vague to encourage users to spot bugs in areas that you (as a developer) haven't thought about.

Be on top of the bugzilla lists. KDE only works if all developers are on top of triaging their own products, confirming bugs, closing duplicates and invalid bugs and of course, fixing them 🙂

As a distro packager, how can I help?

Make sure our wiki page of "how to get the latest beta" (http://community.kde.org/Getinvolved/Quality/Beta/4.10/Installing) is up to date with clear instructions. A link to the relevant release page is enough. It's a wiki for a reason, edit away 🙂

Help co-ordinate

You may have noticed we're running a bit behind this release. We really need to step it up, both now and for future releases. It's a new-ish team, and I've ended up being ridiculously busy.

We have a number of ways to get involved in the managing side of KDE Quality:

  • Redesigning the landing wiki page to be more graphic, easy to navigate and inviting
  • Updating our list of changed areas in 4.10 that need extensive testing
  • Co-ordinate with the kde-promo team to include testing instructions on the release notes
  • Hang around our IRC channel #kde-quality to help answer testers questions

It's a real work in progress, but we're already showing real results both in terms of bugs reported, and bugs fixed.

Join our mailing list [https://mail.kde.org/mailman/listinfo/kde-testing] or find us in #kde-quality.

KDE Testing in 4.10

As usual KDE is running the testing program throughout the beta period
of KDE 4.10. It's a great way to get involved in KDE.

How do I get the latest release?

The latest release for testing can be found on our wiki page http://community.kde.org/Getinvolved/Quality/Beta/4.10/Installing
we try and keep this up to date with the latest information from your distribution.

I've got the latest beta, what should I do?

When you have the latest beta, have a play with the new release and report any bug to http://bugs.kde.org and select "File a bug".

Bug reporting is an essential part of the testing process, it's especially important to catch regressions, which is when a new bug is accidentally introduced when something is changed. KDE developers only have limited hardware and our own workflow, we really do need you to help test and see if you find any bugs we've missed. All bugs are looked at, even if they cannot be immediately fixed and reacted upon.

If you are playing with the release, it is especially helpful if you try using the areas of KDE that either contain new features or have undergone significant changes "under the hood". We have a list of the areas that you should spend some of your time testing on our wiki http://community.kde.org/Getinvolved/Quality/Beta/4.10/AreasToTest. We also have various checklists that should be completed before the release http://community.kde.org/Getinvolved/Quality/Beta/4.10/Plasma

KDE Telepathy 0.5.1 Released

Today we are releasing 0.5.1 of KDE Telepathy, the first patch release in our 0.5 series.

We have fixed over 14 bugs since release, including:

  • Skype no longer appears in the list of available protocols if it is not available
  • Fixed issues when KWallet is disabled
  • Log viewer crashes fixed
  • Loading logs for facebook users
  • Fixed log viewer not showing names in group chats
  • Added an indication that an account is connecting in the presence applet
  • Presence applet autohides if the user has no telepathy accounts
  • Presence applet fits in smaller panels correctly
  • A full list can be found here

    Many thanks to the entire KTp team, as well as to all the testers and bug reporters who helped in this release.

    Source code is available here and it should be in distributions shortly.

    Find out more about getting involved in KTp here

    An update on Extra Mile

    The aim of the extra mile project is put some energy into fixing the little annoyances in KDE, the small bugs and UI issues which get in the way of the user.

    We've been working on areas all over KDE, I've outlined some of my favourite changes I've been working on over this past week.

    Redoing the Network Manager Authorisation Prompts

    This prompt is for when you need to re-enter a password for your wifi connection. The main issue is that the layout cut short, but it is also lacking clear context as to what the dialog is asking. Important text and instructions should be put in the window and not only in the windor title. A bit of text and an icon shape everything up nicely.


    Before


    After

    Improving the Akonadi KCM

    Padding and margins are one the most important tools to a designer, uneven and misaligned spacing can quickly make a really good piece of technology look unfinished.


    Before


    After

    Improving Kate dialogs

    Aurélien Gâteau made some changes in the kate dialogs, updating icons to reflect the actions and updated the tooltips to give a appropriate description of the actions each one does.

    Get Involved

    There's still lots more to be done, and it's a great opportunity to get involved in KDE or even just getting more familiar with a different area of KDE.

    There are two ways to get involved in the extra mile project. We need people to go through applications, dialogs and workflows spotting areas where we can improve by opening extramile bugs, as well as going through this list and getting things fixed.

    Find out more about the project on the wiki page, or join us in our IRC channel #kde-quality on Freenode.

    A week of awesome contributors

    When dealing with bug reports, getting bugs that you can't reproduce is one of the worst situations to be in. Without the right information it's impossible to progress. Knowing where the bug is is 90% of bug fixing, if we are unable to reproduce something it's frustrating for everyone involved.

    This week two bug reporters have stood out as being absolutely fantastic. So much so, they deserve a shout out on PlanetKDE.

    Mohammad Al-Rashed, when he encountered a bug we could not reproduce, not only managed to find out it was reproducable if KWallet was disabled, but recorded and sent us a video of it happening. With this extra information, the bug was fixed within a day.

    I also had a bug in LightDM that I couldn't shake. The bug only appeared in OpenSuse, and caused the entire KCM to crash. Weirdly, it never crashed when launched from kcmshell, but would crash every time it was invoked from System Settings.

    I challenge anyone reading this could have a guess as to what would cause that, I certainly couldn't. Without being able to reproduce this I had absolutely no hope of fixing this.

    Alin Marin Elena kindly went to the effort of giving me SSH access to a machine he set up specifically to reproduce this bug. That night I was able to work out what caused the crash, and another developer Hrvoje Senjan managed to trace it to the specific compile flag being used in the Suse packages that caused this bug to manifest itself.

    The moral of all this is if you're waiting on a developer to fix a bug, be proactive and go beyond the call of duty to help supply all the information needed to fix it.

    LightDM-KDE 0.3.0 Released

    LightDM-KDE 0.3 released

    I have just released version 0.3 of LightDM-KDE, the new alternate KDE login manager. LightDM-KDE is set to be the new default login manager in the next release of Kubuntu.

    This release brings many bug fixes including:

    • No flickering between the greeter and KDE splash screens
    • Better keyboard navigation
    • Last user to log in is remembered and automatically selected
    • Background images can be scaled either keeping the aspect ratio, or stretched
    • Translations have been included
    • Many more fixes...

    A special thank you goes to Nuno Bento, Ralf Jung and Michael Zanetti for their contributions this release cycle.

    Downloads are available at here or in Kubuntu repositories shortly.

    KDE Telepathy 0.5 To Be Released Next Week

    Over the last two months we have been preparing to release version 0.5 of KDE Telepathy.

    This release brings over 50 bug fixes and 500 commits since 0.4.

    About our release cycles

    Every alternate release in KDE Telepathy does not bring many new features, but instead puts the focus on bug fixes, minor improvements, and putting on the extra polish throughout our current feature set.

    This release schedule allows us to do more than simply patch releases as we are able to fix any strings or add code where it is needed. This also encourages us developers to spend the time on improving our code rather than chasing new (more fun?) ideas as the master branch is still closed for large features.

    How can I get involved?

    There's still plenty of room for more testers, and there are plenty of things that can still be improved upon. For further details please see our wiki page, or join us in #kde-telepathy on freenode.

    LightDM-KDE 0.2.0 Released

    After far too long, I'm happy to announce LightDM-KDE 0.2.0!

    Fixes since 0.1.1

    • Suspend when closing lid (Bug #295693)
    • Config should be saved only once (Bug #294964)
    • Port to Plasma Components (Bug #294965)
    • User pictures are not shown (Bug #296303)
    • Selecting "Previously Used Session" with Guest causes login to fail (Bug #298658)
    • Nothing is translated (Bug #299381)
    • Shutdown button in the login screen does nothing (Bug #299881)
    • One can select to auto login as guest, even if guest is not enabled (Bug #300329)
    • Change default lightdm greeter (Bug #303014)
    • Misc visual improvements

    Where can I download LightDM-KDE 0.2

    Requires lightdm v1.3.2 or higher available from https://launchpad.net/lightdm

    Is it usable

    Yes definitely, this second beta release adds even more stability and functionality.

    Getting involved

    Want to help? If you can draw artwork or want to help fix some of the bugs get involved! Email me directly (email address is at the top of any source file), alternatively join the very quiet IRC channel #kde-lightdm on freenode.

    Experimenting With Telepathy Tubes

    During Akademy Daniele Domenichelli and I held a workshop on Telepathy Tubes and how they can be integrated in your application.

    What is a Telepathy Tube

    In Telepathy, a tube is a method of sending arbitrary data between two contacts over the XMPP stream. This is abstracted to the developer in the form of a local TCP socket or a separate Dbus session between the two computers. This allows you to set up a network connection without having to worry about all the difficulties of IP addresses, firewalls, routing and NATs.

    In simple terms, it allows you to exchange more stuff with a contact than the normal text, files or video traditionally associated with instant messaging.

    Fun and Games

    After the workshop Daniele and I decided to try and add Telepathy tubes to an existing KDE application, in this case KBattleship.

    We added a button to the main menu such that instead of starting a game by having to manually type in hostnames and port numbers we simply select a contact from the menu. Considerably easier!

    From here we simply select the contact, and all the network setup is handled in the background.

    I then lose dramatically.

    Having a Go

    I don't expect this to be merged into KDE Games anytime soon, we need to get our internal libraries complete and stable. This was just a fun hacking project rather than anything serious.

    We need the latest kdegames libs

    svn co -N svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegames
    cd kdegames && svn up cmake libkdegames libkmahjongg
    cmakekde

    and my patched version of kbattleship.

    git clone git://anongit.kde.org/scratch/davidedmundson/kbattleship.git

    If you have it installed, let us know.. maybe we can have a game 😀

    Moving Forward

    This was primarily just a demo to see how quickly we can hack Telepathy into an existing application that has network support. It took us less than 3 hours to have something working.

    There are far more practical, exciting uses and it would be really good to see more people make use of this. If anyone is inspired and wants to hack on something cool, come talk to us on #kde-telepathy on freenode.

    Improving the KDE Usability Review Process

    During the workspace sprint I had several discussions with the Usability expert Björn Balazs (of open usability fame) about how to bridge the gaps between usability teams and developers, how to improve the communication and trust between the two and how to increase involvement.

    One of the actions we undertook was a trial run of offering the chance of usability input during the code review process. To do this we have added a usability group on reviewboard which can be assigned to add a UI check to any code checking.

    Developers, from now on if you create a patch that has a significant UI change, such as the introduction of a new dialog simply add the group "usability" to the list of groups that should review your code in addition to the normal maintainer group. The usability team will be notified that you want them to review and make any comments we deem needed or hopefully just told the team approve. If you do this, you should make sure your patch on reviewboard is accompanied by screenshot(s). Ideally in the form of "before", "after" where applicable.