Posts Tagged ‘kde’

UDS Days 2-5

June 10, 2009

I never got around to more blogging during UDS, but here’s a summary of the rest.

We had a discussion with Canonical’s Rick Spencer about the role Canonical’s desktop team is or should be playing in Kubuntu and how to avoid problems we’ve had in the past.  Conclusion: communication communication communication.

Then there was a session on Wine integration and what to do when a user clicks on a windows program.  Will need to keep up for Kubuntu.

We had a session on QA in Kubuntu.  We discussed how to avoid major problems we’ve had in the last couple of cycles and how to improve our QA process in general.  There was also a separate session about l10n problems.  The interesting thing that came out of this is a plan to have a feedback plasmoid on the desktop during the development cycle so we can pick up on problems quickly.  We also decided to expand the use of the Apport bug reporting tool and crash handler in Kubuntu.  The QA team has some neat plans for this tool, some of which are already being implemented, so hopefully the overall quality of bug reports will keep improving.

We had some discussions about the default IRC client and web browser for Karmic and came up with features we’d like to see in our options.

Several of the KDE guys and I sat in on a session about the messaging applet.  It really helped us understand what the Ayatana team is going for.  Sebas then showed off lion mail, which is similar in some ways, and several productive sessions kicked off regarding how to create a messaging indicator for KDE that both follows the DX team’s vision and the KDE way of doing things.

Riddell showed off some of the social web plasma applets available and we decided to include one or two by default in Kubuntu Social from the Start.

There was a session about what we need for KDE integration from Ubuntu One.

We had a session discussing the Kubuntu web site where we mostly talked about how much we like the Xubuntu website.  We came up with some things we can improve on the site, but most importantly, DESIGNERS WANTED!

There was a session discussing creating a way to create a bootable USB stick in KDE, and work is underway.

The last session I went to was on Canonical desktop and usability team’s “Death by a Hundred Paper Cuts” project.  The project will find and try to fix a hundred seemingly trivial usability bugs each cycle.  Neat!  We won’t get the benefit of the professional user testing on the KDE side of things, at least not during the current experimental stages of the project, but maybe we can start a similar initiative?

On the social side, we went out to a bar to watch the European soccer championship game, Barcelona vs. Manchester.  Quite a time and place to be in Barcelona.  Friday night was of course karaoke — barbie girl and bohemian rhapsody KDE style, and some other umm.. good shows.


KDE Konqueror Bug Day May 18

May 14, 2008

This coming Sunday, the 18th of May, there will be a KDE bug day held in #kde-bugs focusing on triaging Konqueror bugs. All Kubuntu and KDE users are invited to participate to help make the next release better. Information about triaging KDE bugs can be found here. From the announcement:

Bug Days are hosted by the KDE Bugsquad approximately once every two weeks. Their purpose is to check back through the large numbers of bugs stored in the KDE Bug Tracking System and investigate how to reproduce them. This means that when developers come to the bug reports to fix them, all the information they need is available on the report and they don’t have to spend huge amounts of their time investigating the bugs – they can just focus on fixing them. During each Bug Day, we will focus on one area of KDE in particular. For this Bug Day, we will be focusing on general bugs in Konqueror. More information can be found on the Bug Day 4 Techbase Page.

Helping sort through these bugs now will help greatly in having a polished KDE/konqueror for the Intrepid Ibex. In addition to the KDE triaging procedures, it will help to look through the Konqueror bugs on launchpad and cross link them with the KDE bug you are working on. This is especially helpful if you can find crash reports from apport since they provide all the debugging information the upstream developers will need to fix a crash.