Triagers and testers needed…

… for a bugsprint about Kmail!

I had the great pleasure to meet with Kmail developer Laurent Montel at Akademy in Tallinn and we discussed the state of Kmail bugs. We agreed upon the work that needs to be done on that occasion:

Currently Kmail 1.x is not maintained anymore, but still has quite a bunch of open reports. Due to a serious lack of time and resources the database went a bit out of hand and now needs some triaging love. While it currently is closed for new bug reports, we aim to get this cleaned up and find the usable bug reports for Kmail2.

What needs to be done?

  • We need to get rid of open duplicate reports.
  • We will check if a bug is reproducible in Kmail 2 and reassign it there.
  • We will close the Kmail1-only reports as unmaintained.
  • We also need to clean up and remove duplicates form the Kmail2 bugs list.

To make sure we can work reasonably well, this is the setup you should have to help with the testing:

  • KDE SC 4.8.4 with Kmail 4.8.4 at least, but 4.9 would be better and if you can run from Git it would be even more helpful.
  • Either a POP3 or an IMAP setup, to make sure we can test both extensively.

When?

Since this will take quite some time I propose 2 weeks in a row, where you can get in and out at your leisure, with a clear focus on the weekends. I will be around most of the time (in my UTC+2 timezone at least) and will try to give a hand in #kde-bugs on irc.freenode.net

So let’s meet on Saturday, August 18th on #kde-bugs and get this sorted as much as possible.

Of course, you can start earlier: you will find two saved searches in b.k.o called “Kmail1 open bugs” and “Kmail2 open bugs”. To find these, go to your Preferences -> Saved searches and add these to your footer, so you can easily access the list whenever you feel a triaging itch. If you don’t see the saved searches then you probably don’t have enough rights on KDE’s bugzilla yet, but that can be improved easily, just ask me.

If this is your first triaging experience, don’t be shy, just ping me in #kde-bugs – type: “Mamarok: ping” – and I will try to give you the necessary help ASAP :)

And finally: if you want to be kept updated about the Bugsprints we organize, you can subscribe to this Calendar: KDE BugDays

flattr this!

Posted in Bugs, Community, Free Software, KDE, Kmail, testing | Tagged , , , , | 7 Comments

Kubuntu Council Elections 2012 – We Need You!


We Need You!

As already announced by Harald on Kubuntu.org, we need new members for the Kubuntu Council.

Don’t forget the deadline next weekend! Hurry up, get your wiki profile updated and submit your candidacy to the Kubuntu-devel mailing list.

I decided to run, what about YOU?

flattr this!

Posted in Community, Kubuntu | Tagged , , | 2 Comments

Beta testers – we need you for Amarok 2.6

We just published Amarok 2.6 beta 1 and need testers:

You can get the tarball from the link on our homepage or ask your friendly distribution packagers to package it for you. Some might already have done that anyway :)

To build from the tarball, you can follow the instructions from our wiki.

Please focus mainly on the new features listed in the article and in the ChangeLog as well as the features you use most, but please also have a look at the (still incomplete) list of tests. Feel free of course to add tests to that list, too.

We would be very glad if you could report the bugs you find right away by using this link: Enter Bug: amarok. Feel free to ping me (Mamarok) in #amarok on irc.freenode.net if you need more information.

Happy testing!

flattr this!

Posted in Amarok, testing | 3 Comments

BKO: when did YOU last test your own bug reports?

After Martin Gräßlin’s excellent blog series for developers there is little I can add but agree on all points. I am currently adding versions to the existing open Plasma bug reports and that made me think of something:

When did YOU last test your own bug reports?

We have all submitted bug reports at some point, be this as a user, a beta tester or a developer. But when did we last follow-up on our own reports?

BKO makes it easy to follow up on my own reports as there is by default at least one saved search visible in the footer when I am logged in: “My Bugs”. Just a click on the link will show me a list of all bugs I ever reported that are still open.

As a user I try to do this on a regular basis, depending on the products I submitted the reports to, but at least on every version change. Since I am the one who reported it who else than me is the best person to actually test if the bug is still valid?

As a beta tester I of course test again when final is released.

As a developer I would probably test when I find time to, but at least on every major version change. So since 4.9 is around the corner this is a good occasion to put this on your ToDo list for the beta testing period :)

Oh, and I almost forgot:

Technorati: that one is for you: DJRCBBT3H7RC :)

flattr this!

Posted in Bugs, KDE | 1 Comment

Great students, great work done!

During 2 months a couple of students aged between 13 and 17 have been helping to solve KDE tasks during the Google Code-In contest. As last year I did mentor a few of them, 19 to be precise. To give you a short update on how much work was done, here comes a list of their achievements:

 

  • Number of tasks: 34
  • 22 KDE bug triaging tasks (9)
  • 5 Amarok wish-list cleaning tasks (5)
  • 5 Amarok Userbase Manual update tasks (5)
  • 2 Amarok webpage creation tasks (2)

2 Students also worked on different tasks, just in case you wonder why the numbers are different here :) Now 34 tasks seem little work, but the numbers behind the tasks are quite impressive:

  • Amarok wish-list cleaning: The task consisted in installing the latest Amarok 2.5 version and testing 50 wishes to check if some might have been implemented and forgotten to be closed. There was a total list of over 450 wishes to test, and indeed all 459 wishes were tested!
  • Amarok Userbase Manual update: it consisted in going through all chapters of the current handbook and update it to version 2.5, changing text and screen shots.
  • KDE bug triaging tasks: the most impressive of all, as the students did triage over 750 bugs, finding many duplicates and even already solved ones and help reducing the bug count considerably.

All this work would not be possible if KDE and Amarok were not Free Software as it empowers the users and the developers alike and gives great opportunities to students to improve their skills. That is just one of the reasons I love Free Software :)

flattr this!

Posted in Amarok, Free Software, Freedom, FSFE, KDE | Tagged , , , | Comments Off

Get your Christmas presents: Amarok 2.5 and KDE 4.7.4 on Windows!

Our KDE-Windows team has been working silently in the background to present you a whole new experience: You can now use your preferred Desktop experience and Audio player on MS Windows, too!picture by Patrick von Reth

Indeed, Amarok 2.5 is the first stable version we release on Windows, offering the same options as the already famous Linux version does. To quote Patrick von Reth, the developer who brought Amarok 2.5 to the MS Windows platform: “In 2005 when I first used Amarok on a Live CD and whished they would support Windows I never imagined I would be the guy who would help bringing it to Windows”.

As a special Christmas gift you can now use the KDE 4.7.4 software compilation on Windows as well. Although still not considered stable and suitable for production work, it is worth a try as it brings a lot of improvements such as the brand new Konversation IRC client 1.4 version, the personal finance manager Skrooge in version 1.1.1 to only name a few KDE applications and, as a technical preview, the speech recognition software Simon in 32-bit. You can get Amarok 2.5 as a standalone product or, even better, install it together with KDE 4.7.4 through the KDEWinInstaller.

Don’t hesitate and get your preferred Free Software on Windows as well :)

flattr this!

Posted in Amarok, Free Software, KDE | Tagged , , , | 20 Comments

When is a bug report useful?

Every now and then we get the same complaints about bug reports again: Either it is a complaint by the user who feels her/his report doesn’t get enough attention from the developers or it is the developers who complain that there are too many bad and useless reports making them spending too much precious coding time on triaging bug reports.
Disclaimer: I am not a developer but do bug triaging, documentation writing and application testing.

I think personally that bug reports are an important feedback from the users, provided those reports are indeed useful to the developers. But what is actually a good bug report? I will restrict my explanations to KDE and its Bugzilla bug tracker, but this applies of course to all bug reports.

1. It should be about the most recent version available

I know that not everybody is updating their computer regularly, some people only do security updates which is probably well enough for their use case, but they should also be aware that Free Software is fast-paced and most developers are already working on newer versions and may even be some versions ahead. In general, bug fixes are not backported to previous version by the developers, simply due to lack of time and manpower.

If you use an older version you can still report it to your distribution if they provide support for it, though. Some distributions even do backports, but also rarely to older versions as most do not have enough resources either.
Don’t forget to specify the exact versions of the product and of KDE (available in the Help menu of all GUI applications).

2. It has to be reproducible

A one-time bug is not reproducible, so it is impossible to fix as the developers need to be able to reproduce it to test and search the location in the code where the problem lies. It is also very important to give a short step-by-step guide how to reproduce the bug.

3. The subject and comment must be in English, easily understandable, and searchable

If you can’t report a bug in English, please don’t. The KDE community is international and the working language is English as it is the one most people in the community understand.
We often get reports with subjects like “Doesn’t work” or ” Your application sucks, fix it!”. This is of course not very clear and highly subjective. For a bug report to be useful it must be well described so it can be searched in the database and so it is actually understandable by the developers.
The Subject should be a short sentence summing up the important points of the bug, for example “Product X crashes when clicking on Icon Y”.
You can and should give more details in the following comment, but keep it short and with a clear structure.

4. The report should be unique

Some bugs will hit many people so it is not unlikely that many people will report it. This leads often to duplicate bug reports which need to be eliminated and collected into one unique report. Knowing that more than half of the reports we get are duplicates this will of course cause quite some triaging work.
When reporting a bug a well written subject line will allow to find duplicates in Bugzilla quite easily. It is even easier if it is a crash as usually Dr. Konqi will suggest duplicates by querying the database. In doubt, don’t submit the report but ask in IRC, search the forum or the mailing list of the project if somebody has already seen it.
Bugzilla provides a very good advanced search query one can get used to quite easily.

5. If it is a crash, it should come with a valid backtrace

But what is a valid backtrace? Most distributions will strip the applications files of their debugging symbols to gain space, especially if they ship a CD and/or DVD of their versions. Those debugging symbols can be obtained separately and have file name endings like -dbg (Debian and Debian-based distros), -debuginfo (OpenSUSE) or -debug (Mandriva) for example. You will find more information and more distributions listed in this KDE Techbase summary.
Dr. Konqi will rate the backtrace quality with stars as you can see here:

A duplicate of Bug 282875

As a general rule: do not submit crash reports that do not have 3 stars as something is missing. If you don’t have debugging symbols installed, Dr. Konqi will warn you and provides the opportunity to install them directly from within Dr. Konqi.

Of course, a backtrace should ideally always be posted in the comment and not as an attachment, so it will be searchable in the database. Hint: the important thread is the one that has [KCrashHeader] after the thread header, so you can most of the time strip the other threads.

6. Be available to give feedback if needed

By submitting a bug report you get in touch with the KDE bugsquad and developers. Make sure you will be around to give feedback and you should also be available for testing if needed. If you are not willing to contribute in that way, please do not submit reports as it will be causing more work for other people to test.

7. Be patient and polite

It is not always possible for the bugsquad and/or the developers to get back to you immediately. We get an average of 50 to 100 reports a day, of which most will be either duplicates or invalid, so there is quite some stuff to get through in a day.

Don’t forget that this is Free Software and almost all KDE people work on their projects as volunteers in their free time. So shouting at people working as volunteers is totally counterproductive as they will probably prefer to do something else instead.
Make sure you stay on topic and be polite and helpful in the same manner as you would expect others to behave towards you, this is more likely to make people work on solving the problem.
Another point to consider is that your use-case is not necessarily the unique one, there are often many ways to do things in an application and you know that KDE is highly configurable for the users. Don’t expect to be the one who does use an application in “the standard way” and be ready to accept a workaround.

If you want to help, you can of course also give a hand in triaging to clean up the database. We welcome all volunteers who want to contribute to make KDE even better! Feel free to come to the #kde-bugs channel on IRC and have a look at the links given below.

UPDATE: Just to put this in perspective of the work ahead I asked Ben Cooksley, one of our sysadmins, to give me some numbers:

With the sheer number of reports in KDE’s bugzilla and not enough people to triage, a valid report can well get drowned: as of today, October 20th 2011 the database has

  • 278,805 total bugs
  • 1,173,947 comments
  • 64,469 attachments
  • 234,403 are CLOSED/RESOLVED/VERIFIED
  • 56,301 bugs were resolved as DUPLICATE
  • 20,250 were resolved as INVALID.
  • 40,571 open with the status ASSIGNED/ NEW/ REOPENED/ UNCONFIRMED
  • 3,830 are in NEEDSINFO status
  • 26,174 are UNCONFIRMED and need triaging

Thanks to Ben Cooksley, Martin Grässlin and Will Stephenson for suggestions and spotting typos :)

Useful links:

How to Report Bugs Effectively by Simon Tatham
Bug Writing Guidelines in Bugzilla
Quick Introduction to Bugzilla in KDE’s Techbase wiki
Guide to Bug Triaging by Dario Andrès in KDE Techbase

flattr this!

Posted in Amarok, Bugs, Free Software, KDE | Tagged , , , | 28 Comments

Last week in Amarok

The last days working towards a release

We plan to release Amarok 2.4 at the end of this week and our developers have concentrated their efforts on fixing release blockers and eventual regressions. A lot of users helped us with testing and pushing our favorite audio player through some heavy stress.
Since Amarok has quite a few features it is almost impossible for the developers alone to test everything and testing is a really easy way to help us making Amarok better. So let’s say a big Thank You to the many individuals who gave us some of their precious time.

Google Code-In ended

By Valorie Zimmermann: All good things end, so does this first edition of Google Code-In. For Amarok this was a big success and gave a lot of students aged 13 to 18 an opportunity to get their hands into Free Software development, Quality Assurance, Documentation writing and Translation to only name a few.
In the last 3 weeks, the following students successfully completed their tasks in Amarok:

  • Pedro Oliveira Raimundo
  • MTGap
  • Ivan Nakov
  • Daniel Marth
  • Paul Ivan
  • Eli Manning
  • Samuel Brack
  • Salma Sultana
  • Kristian Ivanov
  • coldblud
  • Goffrie
  • Caleb
  • Sasu Karttunen
  • It was such a pleasure to work with each of these intelligent, hard-working kids. Their emphasis on quality makes me very optimistic about the future of Amarok, KDE, and the free and open software world of the future.

    Bugs and wishes

    As mentioned above, the emphasis was on fixing release blockers and possible regressions. Our developers were really quite busy working on those fixes and invested some holiday time into it to make Amarok 2.4 really good :)
    We again got precious help by a Google Code-In participant, Timothy Lanzi, who tested and triaged iPod related bugs. Despite him being only 13 he delivered a truly excellent task and deserves a special Thank You for his dedication!

    A total of 126 were closed, here are the details:

  • Fixed: 48 reports, of which 11 were crashes, 5 critical or major bugs and 2 implemented wishes.
  • Invalid: 18 reports were not useful for us.
  • Duplicates: 50 reports were marked as such.
  • Upstream: 7 reports concerned a dependency.
  • Downstream: 2 reports were distribution related.
  • Wontfix: 1 report was closed.
  • flattr this!

    Posted in Amarok, Bugs, Free Software, KDE | Tagged , , , , , | 1 Comment

    Last week in Amarok

    Since we were quite busy in the last weeks, here comes a report about the last month in Amarok. The main reason for this delay is the following:

    We released Amarok 2.4 beta !

    You can read all about the beta release here: Amarok 2.4 Beta 1 "Closer" Released
    Please test it extensively and report the bugs and errors you find. Thank you already for helping to make Amarok 2.4 even better!

    Transcoding is here

    By Teo Mrnjavac: The long awaited music transcoding feature from this year’s Google Summer of Code has finally been merged. Currently, transcoding between local tracks is supported with a variety of encoders, while transcoding to media devices is being postponed until we finish some major restructuring in the media devices stack. As the code is quite young it might be a bit buggy, so testing and bug reporting is strongly encouraged.

    Google Code-in tasks

    By Valorie Zimmermann: Our #rokymotion IRC channel has been humming 24 hours a day it seems, with all the Google Code-In students checking in. Tasks were written for an article for the next Amarok Insider, and many pages of the forth-coming Handbook. Since the Code-In continues until January, it seems like the students will help us even more in the coming month! So far, out of 20 tasks I’ve set, only three remain open for claiming, two are being done, and the rest finished successfully! This is a huge gain for Amarok, for KDE, and for the students also!

    At the half-way point, this is what has been completed:

    • Pedro Oliveira Raimundo (pedromundo): an article about APG for the Insider, the Handbook page: AutomaticPlaylistGenerator;
    • Sasu Karttunen (skfin): Handbook pages for the CoverManager and SavedPlaylists;
    • Ivan Nakov: Handbook pages PlaylistFiltering, and Playlist;
    • Daniel Marth: Handbook pages SearchInCollection, and TagEditor;
    • Paul Ivan: Handbook page OrganizeCollection;
    • Salma Sultana: Handbook pages ScriptManager, and ViewMenu;
    • Caleb: Handbook page AmarokMenu; rfw: Handbook page Playlist.

    A round of applause for their contributions to Amarok, to KDE, and to Free and Open Source Software!

    Bugs and wishes

    Over the last 4 weeks we had a more intense bug triaging, especially with the help of Ogynan Angelov and Samuel Brack who worked on the bug triaging task in KDE’s Google Code-In during the last two weeks.
    Overall we closed not less than 187 bugs: 73 bugs have been fixed, of which 22 were major bugs or crashes and we implemented 6 wishes. 8 reports were marked as invalid, 90 were duplicate reports and 9 were reports for bugs upstream. Thank you very much Ogynan and Samuel, you did a tremendous triaging work!

    flattr this!

    Posted in Amarok | 22 Comments

    Podcast: Ian Monroe on KDE Masters of the Universe

    gamaral-at-workGamaral at Work. Image by Martin Cathrae

    KDE developer and master conspiracy theorist Gamaral has recorded a new Podcast episode of KDE and the Masters of the Universe. This time, the main guest is Amarok developer Ian “THE BEARD” Monroe, and co-host of the show is Mark Kretschmann.

    It’s a really good episode, the guys seemed to have tons of fun, and it’s also pretty interesting, as they reveal some secrets, as in every episode of the show.

    Please enjoy:

    KDEMU with Ian Monroe

    flattr this!

    Posted in Amarok, Free Software, KDE | Tagged , , | 6 Comments