In this week's KDE Commit-Digest: Plasma panels now support "drag-and-drop unhide". More improvements for scripted Plasmoids. "Weather" Plasmoid moves into kdereview for eventual move to extragear for KDE 4.2. Lots of reworking the "HTML Validator" Konqueror plugin. Start of a "BomberMan"-like game using Kapman as a base. New game themes in Bomber and KTron. Further progress on the rewrite of Kolf. Start of an effort to refactor game modules in KGoldrunner. A KIPI plugin to export photos to Facebook from KDE photo applications. Support for autoselection in the "libksane" image scanning library. Work towards automatically detecting digital cameras in Digikam (using Solid). Support for importing old feeds from the RSS plugin (from version 2.2) in KTorrent. Work on "Kloss" (bindings for the Lua programming language). Start of an iPod plugin for DeviceSync. Final remaining feature implemented in Ark for KDE 4.2. Initial import of KSSH4 to KDE SVN. Read the rest of the Digest here.

Comments

Set your panel to autohide. It hides. Drag something down to where the panel should be. Before this fix, the panel would stay hidden. Now it will unhide, so you can drop something in the previewer or opener or pastebin or whathaveyou.

Really, the closed bug count should be a bit less for me and John, but the weekly stat sometimes is not correct. The right count for the last week is something like this:
- Leonardo Finetti (me) about 200 bug closed
- Dario Andres is right: 128
- John Layt about 50

Indeed :-)
Usually during the last month, my average closed bugs count was about 100/200 bugs per week, you know, there are a lot of dups, solved issues, bugs reported without sufficient information for understand the problem and so on...

Anyway I'd like to thanks the bugsquad team which is working a lot to keep bugzilla tidy as much as possible :-)

Firstly, I love the Commit Digest for letting me keep a gradual eye on what's shaking right now.

Aaron -

I'm incredibly impressed by the cooperation in stomping bugs by users who recognize the need to reproduce and narrow down the source as much as possible before a dev gets involved to look at code. I've seen some end-users do some great research on complex bugs--such as bugs involving unexpected behavior between KDE/Qt and non K/Q libraries--to help the KDE dev team know ahead of time more about what's going on and where to start. It's rare to see a community/end users so tightly knit with the developers.

I guess my point is that I'm proud of everyone for the work they do on both sides of the fence and how comparatively little complaining goes on for an OSS project, particularly one of the magnitude of KDE.

Yeah, I've just being doing some bug cleanup in preparation for 'officially' declaring KDEPrint Unmaintained, there's only a couple of real bugfixes in there. The majority (470) comes from my having noticed that a lot of very old bugs were only marked as Resolved and not Closed and deciding to clean them up. Turns out, after having spammed a lot of people (sorry!) that bko considers Resolved as the equivalent of being Closed (although not everywhere), which is contrary to my 'real world' experience. I guess our lack of a QA team means we can't rely on anyone to validate the resolution before closing them. Perhaps we need to educate the people who opened the bug that they should be closing them once they've confirmed the resolution works.

There's a couple of things this I think should come out of this.

Firstly, there's nowhere that explains the full KDE bug lifecycle, what the different status's mean, when you should change them, what are the valid state changes, etc. Someone who knows should document that in techbase, and put a help link to there from bko.

Secondly, the 'Closed Bugs' stat really needs a better definition. We should only count each bug once, so when it gets changed to Resolved, or gets changed to Closed without having been set to Resolved first. Perhaps we also need a second table for the top bug fixers, i.e. those who set a bug to Resolved Fixed?

Finally, to keep things really tidy, we should have a script to automatically set Resolved to Closed after say 12 months with no feedback. Or automatically set to Closed as soon as it's set to Resolved. Or perhaps we need to revise the entire workflow, get rid of status's like Resolved and Validated and Assigned, and just have a streamlined New -> Confirmed -> Fixing -> Closed flow. Either way, the process needs a clean-up.

Forgive my ignorance, but does the original bug-posting user automatically get an e-mail jab in the arm to see if the fix works when the bug is set to Resolved?

I'm thinking a you post it, it's your responsibility to make sure it works kinda thing. Perhaps logging into bugs.kde.org should have a "You currently own [X] bugs that are Resolved but not Closed. Click here to view them." banner near the top.

I've been using the 4.2 line since it was put in the unstable repo at opensuse, many many moons ago. It has been great watching it come along. It is hard to see what will come from 4.3, because 4.2 is just so friggin amazing.

Hey Danny! Congratulations for catching up with the digests! Thanks for putting in the work, and don't worry about getting the extra digest-special news/reports in. They are really wonderful when they are available to read, but having the digest come in every week is special as it is.

Actually, it was a pleasure to get a sense of scope and comparison of activity from the last two months all in one week. I hadn't done much comparison of bug/commit activity before but it was pretty interesting.

At last I have a working KDE4 install (4.2 Beta 2) with a beautiful activity bar (making up for a spacer, but also looking beautiful). Two things.

1. My install experience was nothing short from hell. I had to uninstall Guidance (because Guidance crashing with PowerDevil is not a beautiful experience to have), and fight kmouth to death with kubuntu-experimental repo. If you have an experimental repository, wouldn't I expect you update your packages ASAP (to fix some things, and to break others, but that is going to be expected)?. Please, do it. And bring along RC1 packages.

2. Can I give kudos to everyone involved in Plasma? The Activity Bar turned an unusable feature (activities) into a powerful way to maintain a tidy desktop. I feel GNOME is going to rot, rot and rot in this machine...

Keep in note: I actually know what I'm doing and know the issues I can face with experimental repos. What I don't like is the lack of daily fixes in their experimental repositories. When I add an experimental repo, I expect breakage, but I also expect that breakage to be detected and fixed in almost an hourly basis. That happened with Fedora, Arch Linux, and Gentoo, and I don't really know why Kubuntu does not follow that way of thinking if they are managing an experimental repo. So, blame on them.

1. Blame kubuntu for your install problems, as that is part of distro responsibilities. Though when you use experimental repos, you should expect such problems.

2. And prepare for more cool improvements in next releases, as in KDE 4 the groundwork was laid for many more powerful features. The devs only need time to flesh out the user interface part for many things that are unusable right now. The activities are only the tip of an iceberg :).

I have no idea whether anyone has applied, or whether everyone who has applied was found to be unsuitable, or even what the job involves: if you're being hired to cripple KDE so that it matches what GNOME does (e.g. implementing Mark's "controversial" notification system in KDE), then I imagine that most KDE developers would run a mile :) Or it could be that you're mainly given a free hand and a "make upstream KDE as good as you can, however you can. Here's a salary so you can quit your job and work fulltime on it!".

Harald Hvaal (metellius) committed a change to /trunk/KDE/kdeutils/ark/plugins/libarchive/libarchivehandler.cpp:
Implementing deleting files in tar.gz/tar.bz2 files, the last remaining feature for this release

I think there should be more focus on removing bugs and minor glitches. We want people to use KDE 4 and dont want them to sit on KDE 3.
Now for example, one problem was that Konqueror 4 didnt easily accept browsing behind a proxy but it seems to work in KDE 3. (One old bug).

Of course there are more, but maybe more attention should be on removing bugs rather than making everything perfect right now. We dont want people to still ask the question KDE 3 vs KDE 4 in the year 2010, or do we :)

I'm curious if KDE development gained, or lost momentum in light of this recession. Did we gain lines of code because of the recent layoffs (by volunteers in their spare time), or did we lose valuable coders, because they are no longer paid (to code at work, or in their freetime)