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!

=-=-=-=-=
Powered by Blogilo

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

Tags

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:

=-=-=-=-=
Powered by Blogilo

Aside

Great students, great work done!

Tags

, , , ,

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 🙂

=-=-=-=-=
Powered by Blogilo

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

Tags

, , ,

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 🙂

=-=-=-=-=
Powered by Blogilo

When is a bug report useful?

Tags

, , ,

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

=-=-=-=-=
Powered by Blogilo

Last week in Amarok

Tags

, , , , ,

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.
  • =-=-=-=-=
    Powered by Blogilo

    Last week in Amarok

    Tags

    , , , , , ,

    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!

    =-=-=-=-=
    Powered by Blogilo

    Podcast: Ian Monroe on KDE Masters of the Universe

    Tags

    , ,

    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

    =-=-=-=-=
    Powered by Blogilo

    How to submit patches for Amarok

    Tags

    , ,

    If you followed the Amarok development in the last 18 months, you have seen us move from SVN to Gitorious, and finally to KDE’s own git implementation, projects.kde.org. For patch submitters  and other external contributors there was always a bit of a confusion on what is the best way to submit code to Amarok. Unfortunately there have always been several ways, with the risk of loosing track of the patches, which is a sad side effect when there is too much choice.

    Since we moved to git.kde.org, we now also have a reviewboard! It is available here: git.reviewboard.kde.org and this is the perfect place to submit code for our project. String or feature freeze and code “not just ready” is no excuse to not use the review board

    So to all contributors: register at identity.kde.org and show us your code 🙂

    Important: Please, subscribe to amarok-devel@kde.org and first talk about your ideas there. Good ideas are often shared by more than one person and that can avoid two people working on the same implementation without knowing about each other. It is really mandatory for all contributors to talk to the team about their ideas before even starting to code to avoid such problems. And of course, don’t forget to read our HACKING guide!

    =-=-=-=-=
    Powered by Blogilo

    Seventeen…

    Tags

    , , , ,

    .. is the total number of countries where the Multimedia/Edu sprint participants in Randa are from. You read that right: seventeen! We had developers from Austria, Brazil, Croatia, Denmark, France, Germany, Greece, Holland (the Netherlands), Italy, Norway, Peru, Poland, Scotland (yeah, I know…), Spain, Switzerland, Ukraine and the USA.MmEduSprint

    Impressive, isn’t it? So sad I had to leave this afternoon already, but here are a few highlights of the weekend: we had a very talented chef who spent his holiday to prepare our yummy meals, very productive sessions in the various rooms of the huge building during the day, dsc_0945_smallgorgeous weather, the worlds most beautiful mountain right around the corner ( I am biased 🙂 )dsc_0823_resized and of course the mandatory Raclette evening, prepared by Mr. Fux: dsc_0820-small And here is the man who made all this possible: Mario, the most efficient Sprint organizer I know:dsc_0813_resized Kudos, Mario, well done!


    I should not forget the reason why we were in Randa: Amarok and the Mulitmedia people gathered in this lovely Swiss village to concentrate on various themes, amongst them the current state of Amarok and it’s roadmap, presenting the state of Pulseaudio, sharing a vision of the Multimedia future, possible uses of Nepomuk in Amarok, and many more like Sound events in KDE, a VLC presentation by Jean-Baptiste Kempf and the future of KMix by Christian Esken. But I better leave it to the developers to blog about the details 🙂


    A special Thank You! goes to the currently most famous man in Norway, Knut Yrvin. He made it possible to have an online presentation and discussion over the phone with the Qt Multimedia developers in Brisbane, who kindly stayed in their office much longer than usual to talk with us. A big hug to Knut for being such a great Community Manager, and a big sorry from me, I totally forgot to take a picture of him, so I am shamelessly using a picture made by Thorsten Rahn on the Little Matterhorn: dsc_0899_resized And no, they didn’t break it, the Matterhorn is still up in all it’s glory 😉

    =-=-=-=-=
    Powered by Blogilo