Frist psot!

My Thesis is finally at the binders, so my self-imposed KDE contribution ban is finally at an end. Just in time for the Feature Freeze :)

Anyway, I exploited a loophole in my agreement with myself last October and made a small contribution to KDE in the form of KDE4Daily (my argument was that since KDE4Daily didn't actually involve sending any patches to KDE, it wasn't really much of a contribution. Since I was quite keen on the idea of working on KDE4Daily, I readlily conceded the point and allowed myself to work on it).

It proved to be quite popular, and several people asked if it would make a return again in the run up to 4.1. Since none of the KDE4 devs objected to the idea, I'm currently working on it now. Hopefully it will "go live" within the next 24 hours or so, but my terrible upload bandwidth is currently really putting the brakes on.

In the meantime, I thought I'd paraphrase an e-mail I sent to the kde-core mailing list about how the project went last time, and what its strengths and weaknesses were.

To re-cap, the KDE4Daily project had the following goals:

1) To provide low(-ish)-bandwidth (binary) daily updates (generally 20-50MB
per day) of an SVN snapshot of a reasonably wide range of KDE modules (
http://etotheipiplusone.com/kde4daily/docs/kde4-modules.txt )

2) To be able to generate useful backtraces, such as this sample:
http://etotheipiplusone.com/kde4daily/docs/konqueror-backtrace-sample.txt

(Note that inclusion of Qt debug info in backtraces was disabled by default
due to high memory usage when loaded into GDB.)

3) To be self-contained and distro and operating system neutral - KDE4Daily
was provided as a Qemu Virtual Image, and the updates were performed from
within the image itself.


Basically, it aimed to be a way of lowering the barrier of entry to people who
want to test KDE and file bugs and also to confirm that bugs claimed to be
fixed in SVN were indeed fixed.

Over its 7-week run, only ~5 daily updates were missed. The homepage asked
people to mention "kde4daily" in their bug reports, and a simple search
reveals ~54 such bugs:

http://bugs.kde.org/simple_search.cgi?id=kde4daily

Some of these are just "this bug is still occuring in revision 7xxxxxx"; and,
embarrassingly, were actually caused by KDE4Daily itself! The following
weaknesses in the project were uncovered:

1) Backtrace generation was incredibly time-consuming and resource intensive
due to the need to fetch and patch-in up-to-date debug info, which probably
discouraged many testers from generating backtraces.

2) VMs do not provide 3D acceleration/ compositing, so these aspects were not
tested.

3) The usage instructions neglected to detail how to enable sound, so sound
(Phonon, etc) was not tested.

4) Generally, KDE4Daily is a very homogeneous test environment: every
up-to-date install was effectively identical to all others, excepting the
user's personal data/ config files. Great for reproducing bugs; lousy for
shaking out those little corner cases that only 1 in 100 people will ever
stumble upon.

5) I think many end-users approached the project as a way to satisfy their
curiosity about KDE4.0.0 and to watch it progressing, rather than as a means
to help them file bug reports.

6) The partitioning scheme was very stupid and restrictive, and it seems that many people who actually wanted to work on KDE from within the KDE4Daily VM itself were thwarted by it.

Number 6) is already tackled with the 4.1 edition (people have a nice, 20GB, unpartitioned virtual HDD to mess around in :)) and I'm hoping to tackle at least #1 over the next few days (KDE4Daily 4.1 will hopefully have been released by then, but it can be automatically rolled out in an update) - more as and when it happens :)