Kicking a software release out the door is always a chaotic time; the
developers never feel like the software is ready while project management
is trying to put a box around something that can be shipped.
KDE 4, which is
the first major K Desktop Environment release
since KDE 3.5 in 2005,
is currently in this stage. Questions are being asked about
changing deadlines, beta versus alpha quality software, whether a stable
release can be delivered on time, and so on. The questions reflect an
underlying concern for the quality of the final release.
Part of the problem, it seems, is that earlier beta versions of KDE 4 did
not get widespread use. There were enough fundamental problems that users,
even those expecting a rough ride, were unable to get things going enough
to start filing bugs. Torsten Rahn reported on some feedback he
received at a show:
Almost all visitors who had been long-time KDE enthusiasts and were known
for early feedback in the release cycle had completely failed to
in our Beta program so far (and I know some of these people since about 8
Most of them had tried to build the KDE betas, failed to see a desktop /
appearing and therefore assumed that the apps were not worth testing at the
This is rather alarming given that during a late Beta cycle the targeted
testers should have moved from the developers to the enthusiasts.
It is a difficult problem, a beta must be usable enough for people to work
with it. But if it worked correctly all the time, it would already be
released. For KDE 4, part of the difficulty is that the platform and
underlying libraries are in pretty good shape, "release candidate" worthy,
but the workspace (Plasma) and
applications have lagged. Those are things that users see first, of course;
fundamental bugs will turn them away from testing further.
One project that is helping get more beta testers is the KDE Four Live CD
which is an openSUSE-based live distribution with KDE 4 as the desktop.
Beta testers will not have to build everything from source, nor have to
install anything on their machines. Screenshots from the Beta 4
release version of the live CD accompany this article.
There were some discussions on the kde-core-devel mailing list regarding
whether to call things release candidates, betas, or alphas, with some
advocating recognizing the quality of the code and sticking with a beta
label. In response,
Aaron Seigo makes a good
point about the difference between software releases
in the volunteer-driven free software world as opposed to paid developers
in more traditional development shops:
if it isn't painfully obvious by now, people remain silent and aren't
sufficiently motivated to start the last push work until these things
interesting human behaviour, circumvented in many corporate [environments] by having
managers with unquestioned rights push developers manually. in open source,
useful tool are hard deadlines, names for releases and pushing out tarballs
that are a notch in time.
The distinction is not quite as stark as Seigo paints it, "lines in the sand" are
important tools for any project, volunteer or otherwise. It is the
tension between getting it right and getting it into the
hands of users that cause these conflicts as releases approach. There are
an awful lot of "I can deal with that later" problems that come due.
Determining which are critical and which can be
deferred further is difficult and error-prone. It is much easier for
developers to decide that they are all critical and the release needs to
Sticking to previously established schedules can help by forcing things
out the door, even if they aren't quite ready. Betas and release
candidates are meant to be used, regardless of what they are called –
are also expected to have bugs. The flip side, of course, is that if a
release is unusable, it will be largely ignored. This is what the early
betas of KDE 4 seem to have run into.
In a casual test drive of the Beta 4 release, there were plenty of problems
to be found, but, by and large, it worked. It doesn't seem ready to run as
a day-to-day desktop, yet, but testers and others interested should be able
to assist in finding and tracking down bugs. The existence of a live CD
should help, as will integration with existing installations; imagine being
able to boot the live CD and have it work with the existing users,
preferences, filesystems, etc. on the underlying system. If a showstopping
bug comes along, reboot to the installed OS and file a bug.
Perhaps KDE Four Live does some of this integration with an installed openSUSE, but it did not with the Kubuntu installed on the test machine.
Conflicts in the development process often come to a head when a release is
imminent, KDE 4 is hardly alone in seeing these kinds of disagreements.
Software is difficult to develop and is even harder to release, opinions
will differ on the best approach. In general, though, everyone has an
interest in the same end result – a solid, working final release
– keeping that in mind can help defuse things. The release of
KDE 4 is planned for December 2007, we look forward to seeing it.
to post comments)